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FOREWORD 


TO  ALL  PEA  INFORMATION  SYSTEMS  PERSONNEL: 

This  paper  portrays  the  Office  of  Information  Systems  and  Technology’s  (DLA-Z)  future 
IRM  Environment  Vision.  As  such  it  institutes  primary  IRM  directional  objectives  and  acts 
as  a  seed  for  all  IRM  planning  and  subsequent  implementations.  I  request  that  all  DLA  IRM 
components  be  guided  by  its  tenets.  I  have  already  requested  work  to  begin  on  the 
development  of  real-world  and  target-world  data  models,  the  attainment  of  an  Agency- 
standard  integrated  CASE  environment,  the  inclusion  of  DLA-Z’ s  IRM  business  area  data 
entities  into  modeling  efforts,  the  attainment  of  Cross  Model  Resolution  (XMR)  facilities,  the 
identification  and  development  of  common  business  process  modules,  the  acquisitions  to 
complete  the  technology  array  for  our  design  to  the  "State  of  the  Contract"  policy,  and  the 
update  of  our  open  systems  architecture  policies. 

This  version  of  the  paper  replaces  the  Strawman*.  It  incorporates  comments  received  from 
DLA  organi2ational  components  and  has  been  coordinated  with  the  DLA  Principal  Staff 
Elements. 

Although  this  paper  expresses  the  position  of  DLA-Z  it  is  subject  to  continuing  review  as 
appropriate.  Please  submit  recommendations  for  revisions  to  me  personally  or  to  Bob  Knez, 
DLA-Z  (703-6 17-7 107).  Revisions  that  were  made  since  the  previous  version  are  bracketed 
by  vertical  lines  (  |  ).  Double  vertical  lines  (  1 1  )  indicate  the  deletion  of  text. 

I  appreciate  the  contributions  of  all  of  you  towards  the  continuing  achievements  of  DLA 
information  systems.  The  success  of  DLA  information  systems  is  probably  the  largest  factor 
affecting  the  overall  attainment  of  DLA’s  missions.  The  efforts  involved  in  realizing  the 
"IRM  Environment  Vision"  are  substantial,  but  we  must  move  ahead  to  insure  that  DLA 
benefits  from  the  highest  business  values  achievable  from  its  information  systems. 
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1.  INTRODUCTION 


This  paper  presents  a  concept  and  vision  of  the  DLA  Information  Resources  Management 
(IRM)  environment  for  the  period  subsequent  to  the  consolidation  of  Information  Processing 
Centers  (IPCs)  currently  being  planned  by  DLA  and  by  DoD.  This  places  the  time-frame  for 
the  implementation  of  this  paper’s  concepts  into  the  mid-1990s  and  beyond.  The 
concept/vision  will  be  structured  to  facilitate  the  consummation  of  DLA’s  Conceptual 
Functional  Requirements  (CFR)*’  and  Strategic  Plans',  and  will  set  goals  to  help  focus  the 
human  resources  of  DLA’s  IRM  environment  toward  that  end. 

It  is  understood,  at  the  outset,  that  the  Information  Systems  (I/S)  community,  as  a  whole,  and 
DoD  in  particular,  is  undergoing  enormous  change  from  both  technical  and  cultural 
perspectives.  These  changes  are  being  invoked  by  numerous  paradigm  shifts  in  the  I/S 
industry  as  well  as  by  the  demands  of  a  leaner  DoD  budget.  Although  DLA  will  attempt  to 
influence  external  events,  to  the  extent  it  can,  to  assure  optimum  return  on  its  I/S  investment, 
DLA  can  only  plan  those  events  that  it  has  authority  to  cause  or  can  reasonably  forecast, 
such  as  a  continuation  of  the  trend  towards  increased  cost/performance  of  information 
technology  (I/T),  Thus,  this  paper  does  not  plan  for  or  make  specific  guesses  as  to  which 
DoD  Consolidation  alternative  will  become  a  reality.  Instead,  this  paper  will  prescribe  an 
environment  and  strategies  for  achieving  it  that  are  designed  to  optimize  IRM 
cost/effectiveness  while  remaining  generic  enough  to  fit  whichever  consolidation  scenario  is 
played,  and  to  be  consistent  with  other  major  programs  such  as  CALS*,  MODELS^,  and 
Electronic  Commerce  (EC)/EDP. 

The  number  of  sites  to  be  deployed,  although  portrayed  in  this  paper  for  visual  completeness, 
is  not  a  critical  factor.  What  is  significant  to  define  are;  the  requirements  for  effective 
management  of  the  IRM  environment,  the  concept  and  responsibilities  of  Information 


'cals  •  Computer-aided  Acquisition  and  Logistics  Support. 

2 

MODELS  -  Modernization  of  Defense  Logistics  Standard  Systems. 
^EDI  -  Electronic  Data  Interchange. 
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Technology  Facilities  (TTFs),  a  concept  for  migration  to  the  envisioned  environment,  and  the 
enabling  tools  needed  to  succeed  in  making  paradigm  shifts  in  information  system  application 
and  data  base  engineering. 

Neither  DLA’s  consolidation  plan  nor  the  Defense  Management  Report  Consolidation 
Study**,'  include  |  fundamental  re-engineering  |  of  the  current  automated  information  systems 
(AISs)  or  the  development  of  corporately  structured  data  models.  The  inclusion  of  AIS  and 
data  base  restructuring  during  this  initial  consolidation  would  almost  certainly  prove  to  be 
more  than  DLA  or  DoD  could  effectively  undertake  and  is  best  left  to  a  later  phase  after  the 
impact  of  the  consolidation  has  been  absorbed  and  the  new  environments  are  in  normal 
operation. 

This  paper  deals  with  the  next  phase  -  Re-engineering  the  IRM  environment.  Re¬ 
engineering  provides  the  first  genuine  opportunity  for  the  implementation  of  truly  open 
systems  architectures'*.  The  re-engineering  phase  will  stress  the  implementation  of  the 
seemingly  lofty  ideals  of  corporate  data  bases  and  applications  which  are  assembled  from 
common  application  modules.  It  will  also  stress  the  critical  need  for  comprehensive 
strategies  for  the  migration  of  data  and  processes  to  the  newly  engineered  models. 

I  Several  readers  of  the  Strawman  version  requested  a  capsule  summary  of  the  Vision. 
Hopefully  the  next  page  will  serve  this  need.  For  a  quick  overview  of  the  paper  its 
suggested  that  you  read  through  the  VISION  TENETS  on  the  next  page;  then  read  Section 
6.  EXECUTIVE  SUMMARY.  If  you  still  need  more,  resume  reading  the  paper  at  Section 
2.  PRESCRIBED  IRM  ENVIRONMENT.  1 


‘*Many  older  information  systems  were  developed  for  and  are  dependent  upon  vendor  proprietary  technical 
environments  such  as  non-POSDC  compliant  operating  systems,  non-SQL  Data  Base  Management  Systems, 
telecommunications  monitors,  and  even  assembly  languages.  Complicating  the  issue;  a  variety  of  vendor  dependent 
operational  support  systems  for  scheduling,  capacity  management,  and  direct  access  storage  space  management  may  be 
utilized. 
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[VISION  TENETS 

DATA  SHARING  THROUGH  A  SINGLE  IMAGE  CORPORATE  DATA  BASE 
IRM  DATA  ENTITIES  INCLUDED  IN  CORPORATE  DATA  MODEL 


APPUCAHON  DEVELOPMENT  THROUGH  ASSEMBLY  OF  STANDARD  COMPONENTS  OEGO  BLOCKS) 

DATA  -  SUBJECT  DATA  BASES 
PROCESS  -  BUSINESS  PROCESS  FOUNDATION  MODULES 
TECHNOLOGY  -  HARDWARE  AND  SOFTWARE 


COMPUTER  ASSISTED  SYSTEMS  (SOFTWARE)  ENGINEERING  ENVIRONMENT 
CORPORATE  INFORMATION  ENOINEERINO  REPOSITORY 
BUSINESS  FUNCTIONS 
BUSINESS  PROCESSES 
BUSINESS  DATA  ENTITIES 
BUSINESS  PROCEDURES 


ORGANIZATION 

CENTRAL  DEVELOPMENT,  MAINTENANCE  AND  MANAGEMENT  OF  LEOO  BLOCKS 

APPLICATION  DEVELOPMENT  CENTRALLY  MANAGED  BUT  EXECUTED  IN  A  DISTRIBUTEO  MANNER  WITH  AN  END  OBJECTIVE  OF 
TURl>nNO  THE  IklANAOEMENT  OF  ALL  APPLICATION  DEVELOPMENT  OVER  TO  PRINCIPLE  STAFF  ELEMENTS 

DISTRIBUTEO  INFORMATION  SYSTEMS  OPERATIONS 


INFORMATION  TECHNOLOGY 
■STATE  OF  THE  CONTRACT"  DESIGN  POUCY 
OPEN  SYSTEMS  ENVIRONMENT 
NETWORK  COMFUTINO 
COOPERATIVE  PROCESSING  | 
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2.  PRESCRIBED  IRM  ENVIRONMENT 


j  Many  I  of  DLA’s  automated  information  systems  are  decades  old  and  have  been  developed 
and  modified  through  years  of  changing  technology  and  design  ideals}^  j .  While  these 
systems  continue  to  provide  support  to  DLA’s  Principle  Staff  Elements  (PSEs)  and  its  User 
communities,  they  do  not  j  always  |  facilitate  effectiveness  at  a  level  achievable  with  today’s 
technologies  and  IRM  paradigms.  While  it  may  be  prudent  and  cost/effective  to  complete 
today’s  consolidations  by  simply  combining  the  current  IRM  environments,  we  must  set  our 
subsequent  goals  on  the  optimization  of  the  consolidated  environments  through  re-engineering 
the  environment  in-line  with  the  potentials  accorded  by  modem  technology  and  methods. 

Only  then  will  full  cost/effeCtiveness  be  achievable.  The  above  considerations  apply  as  well 
to  the  entire  DoD  community,  since  even  after  DoD  consolidations  and  “Interim  Standard 
Systems**"  integrations  of  applications  are  completed,  DoD  will  still  be  left  with  systems  that 
need  re-engineering.  As  Yogi  Berra  so  aptly  put  it;  "The  future  ain’t  what  it  used  to  be". 

John  A.  Zachman’s  Information  Architecture  Framework  (see  enclosure  5)  describes  a 
manufacturing  paradigm  for  the  building  of  information  systems.  His  manufacturing 
paradigm  applies  to  all  three  parts  (Data,  Process,  and  Network)  of  an  information  system 
architecture’.  His  data  architecture  description  supports  corporate  data  structures  and  the 
inevitable  separation  of  process  and  data.  At  the  designer’s  level  it  supports  the  development 
of  entity-relationship  models.  His  process  architecture  supports  the  use  of  data  flow 
diagrams  at  the  designer  level.  His  network  architecture  models  the  deployment  of 
technology  which  is  described  as  nodes  and  lines  (links).  The  underlying  theme  of 
Zachman’s  architecture  is  that  I/S  must  mature,  as  other  sciences  have,  and  begin  to  look  at 
itself  as  a  manufacturing  activity  rather  than  a  job  shop.  At  the  Guide  User’s  conference  in 


^Several  recently  developed  DLA  applications  such  as  AIMS  (Automated  Inventory  Manager  Support),  DP  ACS 
(DLA  Pre-Award  Contracting  System),  and  TRIPS  (Travel  Reporting  Integrated  Payments  System)  have  implemented 
new  paradigms  such  as  ClientyServer. 

^Previously  referred  to  as  'Best  of  Breed'. 

’Zachman  is  extending  his  framework  to  include  the  more  abstract  concepts  of  'Role*,  'Timing*,  and  'Motivation'. 
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November  1990,  Jim  Archer  of  IBM  described  the  software  factory  of  the  future  as:  "Model 
driven,  Automated,  Re-use,  and  Re-engineering".  We  can  equate  these  characteristics  to: 


IBM’s  WORDS  THEIR  MEANING  IN  DLA 


"Model  driven" 

"Automated" 

"Re-use" 

"Re-engineering" 


=  Entity/Relation  and  Process  models 
=  CASE  tools 

=  Business  Process  Foundation  Modules,  Standard  Technology 
Contracts,  and  Subject  Data  Bases.  (DLA’s  Lego  Blocks) 

=  Not  just  cut-and-paste 


Put  simply  -  this  concept  means  that  we  must  manufacturej*|  the  parts  (data  bases,  process 
modules  and  network  nodes/links)  and  assemble  them  to  order  (see  enclosure  9).  In  other 
words  a  PSE’s  functional  requirement  |may  be  considered  asj  the  "order"  that  initiates  the 
assembly  of  an  I/S  application  using  standard  parts  out  of  inventory  and  automated  CASE 
tools  to  manage  the  assembly. 

The  following  list  reflects  prominent  features  and  characteristics  of  the  prescribed  re¬ 
engineered  IRM  environment  which  differ  from  the  current  environment  and  are  critical  to 
full  cost/effectiveness.  The  list  is  divided  into  three  parts;  Data,  Process,  and  Network  to 
correspond  with  the  information  systems  architecture  framework  prescribed  by  John 
Zachman^  Fourth  and  fifth  items  on  the  list  are  Technology  and  Organization  to  round  out 
the  overall  prescribed  environment. 


a.  DATA  ARCHITECTURE  ENVIRONMENT 


DATA  SHARING 

DLA’s  strategic  objectives  as  well  as  its  conceptual  functional  requirements 
state  that  its  future  systems  will  share  data  across  applications  through  the 


*The  terra  "nr.anufacture"  is  used  loosely.  It  simply  means  that  the  components  will  be  acquired  by  whatever  means 
are  necessary;  build  it,  buy  it,  etc. 
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development  of  common  subject  data  bases.  Subject  data  bases  aggregate  data 
according  to  data  subjects  instead  of  application  usages.  Thus,  there  is  not  a 
one-to-one  correspondence  between  each  data  base  and  a  specific  application 
because  a  data  base  may  be  utilized  by  many  applications  and  an  application 
may  use  many  data  bases.  This  represents  a  fundamental  paradigm  shift  in  the 
view  of  data  which  is  difficult  for  many  corporations  to  accept  and  to 
subsequently  achieve.  The  aggregate  of  subject  data  bases  form  j  a  single 
image  DLA  |  Corporate  Data  Base.  The  Corporate  Data  Base  will  be 
physically  deployed  by  placing  appropriate  subject  data  bases  at  the  sites  with 
the  highest  frequency  of  reference!’},  replication*®  or  segmentation** 
of  subject  data  bases  will  be  determined  by  the  degree  of  redundancy  necessary 
for  security  or  processing  efficiency.  In  any  case,  replication  or  segmentation 
of  data  must  be  a  design  decision  which  is  accompanied  by  appropriate 
facilities  and  procedures,  |  such  as  recovery  and  audit  trail  | ,  for  maintaining 
the  synchronization  and  integrity  of  the  data. 

As  DLA  performs  the  information  engineering  work  for  the  re-engineered 
subject  data  environment  it  will  also  seek  opportunities  to  reduce  its  own 
requirements  for  storage  and  processing  of  data  within  DLA  in  those  cases 
where  it  is  more  economical  and  effective  to  rely  upon  the  data  originator. 

The  potential  for  overall  systems  integration  of  hybrid  data  is  most  evident  in 
the  logistics  data  management  area*  but  is  likely  to  occur  on  a  much  wider 
scope  due  to  increased  electronic  commerce. 

IRM  DATA  IN  CORPORATE  DATA  STRUCTURES 

DLA  has  a  number  of  mission  areas  j  such  as  Material  Management, 

Distribution  Services,  and  Acquisition  Services}.  DLA’s  IRM  organization 


’other  factors  such  as  physical  space  considerations,  availability  of  maintenance,  and  data  administration  must  also 
be  considered  but  the  prime  target  is  locality  of  reference. 

*®Replication  -  A  redundant  copy  of  the  data  set. 

** Segmentation  -  A  non-redundant  distribution  of  portions  of  the  data  set;  e.g.  The  current  SAMMS  data  is 
segmented  by  stock  class  to  the  controlling  Supply  Centers. 
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has  developed  many  automated  information  systems  such  as,  SAMMS, 
DWASP,  |DLIS| ,  DROLS,  and  MOCAS  to  support  DLA’s  primary  mission 
functions.  Other  DLA  | Corporate!  Support  functions  such  as  personnel 
management  and  pay  administration  have  also  been  supported  by  standard  AISs 
such  as  APCAPS.  Although  these  applications  have  been  developed  under  the 
old  paradigm  of  application-data-bases,  the  data  bases  at  least  provide  a 
common  point  of  reference  across  their  mission  management  function.  Not 
unlike  most  other  large  IRM  organizations,  DLA  IRM  has  not  provided  as 
well  for  its  own  management  fut^ctions.  Numerous  applications  and  data  bases 
exist  in  headquarters,  design,  and  operational  organizations  throughout  the 
Agency  for  the  purpose  of  information  resources  management.  With  the 
exception  of  systems  such  as  ARMS  (Automation  Resources  Management 
System)  there  are  no  standard  AISs  for  IRM. 

DLA’s  future  re-engineered  IRM  environment  will  include  the  data  necessary 
for  the  effective  functioning  of  the  IRM  organization  as  well  as  that  of  DLA’s 
primary  mission  function  and  other  support  areas.  Data  modelling  for  the 
entities  of  interest  to  the  IRM  organization’^  is  as  important  as  the  data 
modeling  for  the  rest  of  DLA’s  data  and  will  become  a  part  of  the  corporate 
model.  This  means  that  applications  that  are  developed  for  IRM  organizations 
(IRM  Budget  Management,  Capacity  Management,  Configuration 
Management,  Project  Management,  Document  Flow  Management,  Acquisition 
Management,  etc.)  will  be  integrated  through  the  common  data  structure.  All 
IRM  personnel  throughout  the  Agency  will  use  this  data  base  as  part  of  their 
normal  routine.  The  adage  may  become  -  If  it  isn’t  on-line  it  doesn’t  exist. 

The  creation  and  routine  use  of  the  data  base  for  all  IRM  functional  and 
executive  information  retrieval  activities  will  assure  consistency  and  integrity 
of  data  for  decision  making,  drastically  reduce  or  eliminate  data  calls  that  are 
habitually  and  repeatably  made  by  study  teams  within  DLA  and  DoD,  increase 
the  sense  of  teamwork  among  IRM  organizational  components,  and  increase 
the  overall  speed  of  service  and  effectiveness  of  managing  the  overall  IRM 


'^Enclosure  6  to  this  paper  contains  a  list  of  potential  data  entities  necessary  for  supporting  the  many  business  sub¬ 
functions  of  the  IRM  organization. 


7 


5  April  1991 


DEFENSE  LOGISTICS  AGENCY 
INFORMATION  RESOURCES  MANAGEMENT  ENVIRONMENT 
VISION  AND  PRESCRIPTION 


environment.  All  of  these  benefits  will  produce  the  desired  effect  of 
improving  the  quality  |and  accuracy  of  dataj ,  and  reducing  the  cost  of  the 
services  provid^  by  the  IRM  organization  to  its  customers. 

b.  PROCESS  ARCHITECTURE  ENVIRONMENT 

COMMON  APPLICATIONS  ARCHITECTURES 
In  the  past,  DLA  and  the  other  services  have  often  developed  application 
systems  from  separate  and  unique  technology  and  functional  components.  A 
case  in  point  lays  in  DLA’s  own  Material  Management  functional  area.  Over 
the  years  DLA  has  developed  three  separate  systems  for  inventory  control; 
SAMMS**,  DFAMS*^,  and  DISMS‘*.  These  systems  do  not  share 
common  business  process  foundation  modules,  data  base  models  or  structures, 
or  technology  platforms.  It  is  a  conceded  point  that  these  systems  are 
designed  to  manage  radically  different  commodities  with  to^ly  different 
considerations  in  regard  to  storage,  shipping,  shelf  life,  acquisition  methods, 
etc.  therefore  the  systems  should  be  unique.  While  this  is  true,  there  are 
bound  to  be  a  number  of  low-level  process  commonalities  which  could  be 
shared.  Certainly  there  is  the  potential  for  the  utilization  of  a  common 
technology  platform  and  common  structuring  methods  such  as  described  in 
Laurence  J.  Best’s  Application  Architecture  for  Modem,  Large  Scale 
Information  processing*",***.  [Little,  if  any,  excuse  still  exists  for  the 
building  of  totally  unique  systems,  j 

The  Services  and  DLA  have  long  been  pressured  to  share  each  others 
information  systems,  that  on  the  surface,  appear  to  perform  the  same  mission 


*^SAMMS  -  Standard  Automated  Material  Management  System. 

*^DFAMS  -  Defense  Fuels  Automated  Management  System. 

*^DISMS  -  Defense  Integrated  Subsistence  Management  System. 

*^Laurence  J.  Best  works  for  AMS  (American  Management  Systems)  who  has  been  studying  and  applying  the 
concepts  of  common  business  foundation  modules  for  a  number  of  years. 
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functions.  Service  resistance  to  the  sharing  of  these  systems  has  always  been 
strong.  The  Services  and  DLA  complained  that  only  their  systems  matched 
the  way  they  did  business,  therefore  the  use  of  common  systems  would  be 
impossible.  Forced  by  economic  necessity,  the  CIM  program  is  addressing 
this  challenge  head  on,  and  will  eventually  succeed  in  forcing  common 
environments.  Unless  the  selected  systems  are  modified  to  meet  all  the 
Service  and  DLA’s  needs,  the  recipient  of  a  foreign  system  will  have  to  adjust 
its  business  procedures.  This  can  be  done  but  will  be  difficult  because  it 
affects  cultures  which  are  driven  by  their  own  inertia.  |  Enclosure  1 1  should 
be  reviewed  for  considerations  that  must  be  made  in  the  implementation  of 
Interim  Standard  Systems  j . 

Discussions  of  re-usable  code,  codeless  programming,  business  foundation 
modules,  shrink  wrapped  software,  and  technology  independent  application 
designs  are  not  new.  The  time  has  arrived  however,  to  take  these  objectives 
seriously  and  to  develop  business  process  modules  that  may  be  utilized  much 
like  Lego  blocks  to  build  virtually  any  application  structure  desired.  The 
objective  is  to  manufacture  the  parts  (modules)  that  may  later  be  assembled 
into  products  (applications)  tailored  to  the  customers  order.  Most  likely  this 
will  require  the  addition  of  outer  blocks  (shells)  of  uniqueness  to  meet  the 
cultural  needs  of  the  users,  but  the  applications  will  be  built  largely  of  off-the- 
shelf  components.  Much  work  still  needs  to  be  done  in  determining  ways 
within  information  engineering  methodologies  to  identify  candidates  for 
common  modules  such  as  is  now  done  in  determining  subject  data  bases  by 
affinity  analysis.  This  work  must  begin  now. 

Emerging  technologies  such  as  "object  oriented"  show  promise  in  improving 
the  degree  to  which  program  code  may  be  re-used.  Objects  inherently  know 
what  to  do  when  encountered  by  other  objects;  e.g.  a  Customer  Account  object 
knows  to  subtract  from  its  balance  when  it  encounters  a  Withdrawal  object. 
This  is  because  the  customer  object  carries  the  balance  data  attribute  while  the 
withdrawal  object  carries  the  amount  withdrawn  attribute  and  they  each  carry 
their  own  process  attributes.  This  is  quite  a  different  concept  for  programmers 
familiar  with  older  techniques  to  swallow  but,  because  of  this  encapsulation, 
should  make  the  objects  very  self  sustaining  and  portable.  This  concept  is 
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much  more  difficult  than  relational,  although  any  work  done  in  relational  will 
help  in  changing  to  an  objected  oriented  paradigm  when  desired. 

c.  NETWORK  ARCHITECTURE  ENVIRONMENT 
NETWORK  COMPUTING 

During  the  next  five  years  I/S  industry  computer  systems  will  increasingly  take 
on  the  form  of  network  computing.  Increased  communications  protocol 
standardization,  expanded  bridge,  j router]  and  inter-net  gateway  capabilities, 
and  increased  implementations  of  client/server  with  cooperative  processing 
systems,  both  at  the  wide  and  local  areas,  will  finally  integrate  computers  and 
telecommunications.  Overall  systems  will  be  viewed  as  computing  networks 
with  data  storage,  processor,  and  gateway  nodes.  Networks  of  networks  will 
be  the  norm. 

1  Although  recently  developed  applications  such  as  AIMS  and  DPACS  have 
been  implemented  in  the  client/server  cooperative  processing  paradigm,  j  the 
majority  of  DLA’s  AISs  are  architected  as  host  ba^  processing  systems  with 
end-user  access  through  non-intelligent  terminals.  Much  of  the  processing  that 
the  host  currently  performs,  such  as  screen  presentation  management,  end-user 
help  screens'^,  and  basic  input  editing  may  be  off-loaded  to  intelligent 
terminals/workstations  which  are  already  available  on  end-user’s  desks.  This 
can  reduce  communications  traffic  between  the  host  and  terminal  considerably 
while  extending  much  greater  power,  ease  of  use,  and  flexibility  to  the  end- 
user.  The  inclusion  of  human  engineered  graphical  user  interfaces  (GUIs)  for 
example,  can  drastically  reduce  end-user  training  requirements  while 
dramatically  increasing  productivity  levels.  A  client  (end-user  workstation) 
and  a  server  (the  host  computer)  where  each  component  of  the  architecture 


17 

A  good  place  to  integrate  expert  system  advisors  into  a  major  information  system.  The  expert  system  would  act 
as  a  supervisor  looking  over  an  operator’s  shoulder  to  provide  advice  on  how  to  react  to  data  conditions  being  observed. 
Neural  network  logic  could  recognize  trends  or  abnormalities  over  a  series  of  many  user  screens. 
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cooperates  in  doing  what  it  is  capable  of  doing  most  effectively**,  illustrates 
the  client/server  architecture  concept.  Data  base  servers  and  print  servers,  for 
example,  are  fairly  obvious  examples  but  the  concept  extends  to  all  types  of 
services  performed  by  one  information  systems  component*®  for  another. 

The  vision  of  network  computing  with  its  many  cooperative  processing  nodes 
will  not  be  entered  into  without  careful  planning.  Although  the  I/S  industry  is 
moving  unrelentingly  into  these  concepts^  because  of  their  ultimate  benefits, 
there  are  perils  to  overcome.  Notwithstanding  the  paradigm  shift  and  the 
attendant  cultural  change  that  IRM  personnel  must  undergo,  we  need  to 
develop  techniques  and  facilities  for  the  care  and  feeding  of  this  complex 
environment.  For  example:  software  release  management  across  distributed 
environments^*,  innovative  licensing  schemes  for  networked  commercial 
software^,  network  management  facilities,  transaction  management 
software^,  operator-less  nodes,  and  end-user  problem  resolution.  These 
issues  will  be  further  addressed  in  the  action  plan  portion  of  this  paper. 


**One  should  not  allow  himself  to  be  trapped  into  becoming  either  a  main-frame  or  a  small-system  bigot.  All  size 
systems  have  unique  potentials  in  the  client/server  environment. 

”The  use  of  the  term  ’component”  in  this  context  means  any  hardware  or  software  component  making  up  the 
information  system. 

^**1/5  industry  pundits  have  referred  to  the  90s  as  the  decade  of  client/servers. 

^'Commercial  software  packages  such  as  NDM  (network  Data  Mover)  by  Systems  Center,  Inc.  have  potential  for 

here. 


^^Floating  software  licenses  and  site  licenses  for  a  maximum  number  of  users  are  becoming  popular. 
AT&T’s  Tuxedo  Transaction  Management  System  has  potential  here. 
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d.  TECHNOLOGY  POLICIES  AND  ENVIRONMENT^ 

Information  systems  technology  is  growing  at  an  extremely  rapid  pace.^  This  high 
rate  of  growth  often  renders  previously  unjustifiable  applications  suddenly 
economical.  In  fact;  ignoring  certain  critical  technologies  may  render  a  competitive 
business  non-competitive  in  short  order.  TTiis  makes  long  range  planning  more 
difficult  today  than  ever  before.  Since  long  range  business  planning  is  imprecise, 
technology  planning  must  be  flexible  enough  to  accommodate  many  changes  in 
business  direction. 

DLA  is  experiencing  many  changes  today;  some  forced  by  the  new  economics  of 
technology,  others  by  new  directions  in  ^e  way  DoD  is  moving  in  response  to 
budgetary  restrictions  and  its  own  realizations  of  current  waste  and  inefficiencies. 

The  creation  of  a  central  payments  activity,  plans  to  consolidate  information 
processing  centers,  and  DoD’s  desires  to  share  common  applications  across  its 
components  are  manifestations  of  these  realizations.^ 

Thus,  DLA  will  not  make  inappropriately  precise  technology  plans,  but  will  assure 
that  it  embraces  appropriate  concepts  that  accommodate  change.  To  do  this  DLA  will 
assure  that  it  maintains  viable  conceptual  directions  (blueprints),  and  viable 
application  building  blocks  (HW/SW  component  platforms).  It  will  utilize  general 
concepts  such  as  cooperative  processing  client/server  architectures  and  integrated  I/S 
componentry  acting  as  the  Lego  blocks  from  which  the  kinds  of  systems  DLA  needs 
may  be  engineered. 


24 

According  to  Peter  Burris  of  IDC  (International  Data  Corporation),  the  cost  performance  growth  of  mainframe 
I/S  technology  can  be  expected  to  approximate  15%  -  20%  per  year.  However,  Peter  projects  that  because  of  rapid 
advances  in  desktop  and  low  end  minicomputers;  that  the  overall  industry  installed  base  of  MIPS  will  experience  cost 
performance  growth  figures  more  on  the  order  of  23%  -25%. 

The  consolidations,  although  reducing  the  number  of  sites  and  significantly  contributing  to  DoD/DLA  cost  cutting 
objectives,  will  require  increases  in  size  and  performance  of  current  systems  therefore  increasing  the  criticality  of 
operating  systems  upgrades. 
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"STATE  OF  THE  CONTRACT  DESIGN"  CONCEPT 
DLA’s  Information  Systems  (I/S)  Technology  objectives  center  around  the 
concept  of  maintaining  a  complete  j array!  of  approved  technology 
componentry  (hardware/software)  that  would  be  sufficient  to  maintain  existing 
systems  and  to  design  the  client/server  systems  envisioned  for  DLA’s  future. 
All  components  on  the  list  must  meet  inter-operability  and  portability 
standards. 

APPROVED  CONTRACTS  LIST 

I/S  designs  will  be  required  to  follow  a  concept  of  "State  of  the 
Contract  Design"  which  states  that  only  components  available  on  the 
approved  contracts  list  may  be  utilized  in  new  system  designs.  The  use 
of  non-approved  components  will  require  critical  reviews  j  by  the  DLA 
organizational  component  responsible  for  systems  integration  |  to  assure 
that  the  level  of  inter-operability  and  portability  is  not  being 
jeopardized.  The  use  of  approved  components  will  be  limited  only  by 
the  cost/benefits  of  designing  the  new  functional 
capability/enhancement. 

EARLY  DETECTION  OF  TECHNOLOGY  NEEDS 
In  order  that  the  list  remains  adequate  to  satisfy  increasing  technology 
demands,  DLA  will  review  new  functional  requirements  as  early  as 
possible  to  detect  the  need  for  technology  that  is  not  currently  on  the 
list.”  When  new  technology  needs  are  detected,  DLA  will  seek  to 
assure  that  available  contract  vehicles  are  in  place  by  the  time  that  I/S 
design  for  the  new  functional  features  is  ready  to  begin.  Since  the 
concept  requires  early  detection  of  future  functional  needs  it  is  evident 
that  precise  definition  of  capacity  and  quantities  may  not  yet  be 
possible,  therefore  contract  flexibilities  such  as  wide  minimum  and 
maximum  order  quantities,  etc.  must  be  negotiated.  Thus  the  concept 
"State  of  the  Contract  Design"  reflects  the  use  of  the  application 


7A 

DLA  utilizes  a  Strategic  Information  Asset  Planning  System  (SINAPS)  methodology  to  capture  functional 
requirements  and  project  the  types  of  technology  that  will  be  needed. 
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enablers  (hardware/software)  available  on  current  contracts  as  practical 
technology  limitations  on  design. 

JOINT  VENTURES 

As  much  as  possible  contract  needs  will  be  satisfied  by  the  use  of 
multi-service  contracts  which  possess  a  great  deal  of  built-in  flexibility. 
It  is  expected  that  the  full  realization  of  the  benefits  of  this  concept  will 
be  the  reduction  or  elimination  of  the  need  for  large  technology 
acquisitions  for  specific  applications.  In  recent  years  DLA  has  become 
a  partner  with  the  Air  Force,  the  Army  and  the  Navy  on  joint  service 
acquisitions.  DLA  now,  due  to  these  acquisitions,  has  a  formidable 
stable  of  contracts  for  I/S  componentry.  Perusal  will  reveal  that  these 
contracts  already  cover  a  large  portion  of  DLA’s  hardware/soflware 
requirements. 


INTEGRATION  GUIDANCE 


The  technical  platform  that  is  developing  consists  simply  of  an  OSA 
approved  list  of  componentry  from  which  hardware/software  would  be 


selected  and  assembled  into  a  wide  variety  of  client/server 
arrangements  as  determined  by  the  designers  to  satisfy  functional 
application  needs.  The  approved  list  will  change  as  new  needs  are 
recognized  and  new  approved  usages  of  components  are  made. 
Therefore  DLA  has  developed  a  "Technology  Integration  Guide"  which 
is  utilized  by  DLA  activities  involved  in  I/S  design  work  to  assist  them 
in  determining  the  appropriate  hardware/software  components  (the  Lego 
blocks)  to  utilize  in  their  design.  It  also  provides  some  degree  of 
configuration  aid.  The  guide  includes  a  summary  of  outstanding 
contracts,  their  contents,  their  potential  use,  their  duration,  technical 
integration/configuration  information,  etc.  It  also  contains  a  summary 
of  ongoing/planned  acquisitions  with  projected  dates  of  availability, 
contents,  potential  use,  etc.,  to  the  extent  that  the  information  is  not 
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OPEN  SYSTEMS  ARCHITECTURE 

At  the  November  1990  Guide  Users  Group  meeting  George  Liptak  of  IBM 
discussed  the  results  of  a  survey  they  had  done  with  their  customers.  Here  are 
what  the  customers  described  as  openness: 

Multi-vendor  inter-operability. 

Enterprise-wide  information  access. 

Consistent  graphical  user  interface. 

Client/server  computing. 

Heterogeneous  system  management. 

Application  portability. 

These  descriptions  are  not  inconsistent  with  DLA’s.  DLA  officially  adopted 
an  open  systems  architecture  policy  as  far  back  as  1986  with  the  introduction 
of  its  Software  Blueprint  and  other  subsequent  policies^, The  DLA  IRM 
Near-Term  Planning  Document  of  May  1990"  re-enforced  this  commitment  to 
open  systems.  The  Blueprint  represented  a  target  for  inter-operability  and 
portability  which  was  to  be  gradually  implemented  as  major  reworks/redesigns 
of  existing  information  systems  occurred  over  time.  It  remains  as  a  major 
DLA  policy  to  guide  application  designs  and  hardware/software  acquisitions. 
However;  the  open  systems  ideals  of  the  Blueprint  are  not  fully  achievable 
without  re-engineering  DLA’s  baseline  AISs  with  a  view  of  data  resources  that 
goes  beyond  specific  application  boundaries.  The  opportunity  for  the  creation 
of  a  fully  open  environment  will  be  presented  when  the  re-engineering  phase, 
prescribed  by  this  paper,  begins. 
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COMPUTER  ASSISTED  SYSTEMS  ENGINEERING  (CASEl 
CASE^  tools,  and  the  concepts  they  allow  us  to  realize,  may  be  the  only 
practical  way  of  dealing  with  the  immense  complexity  of  the  enterprise’s  data, 
process  and  network  architectures^’.  |  A  standard  methodology  for 
performing  information  engineering  is  also  critical".  | 

DLA’s  legacy  application  systems,  which  run  primarily  in  the  IBM  370 
architectured  environment,  pose  a  substantial  re-engineering  challenge.  Most 
organizations  today  are  maintaining  legacy  systems  and  spending  more  and 
more  money  doing  it.  Charles  Bachman  of  Bachman  Associates  points  out 
these  sobering  trends  in  resource  allocations |”j: 

1975  New  Applications  50% 

Old  Applications  50% 

1990  New  Applications  10% 

Old  Applications  90% 

DLA’s  legacy  systems  form  most  of  the  bread  and  butter  I/S  capability  of  the 
Agency  and  must  continue  to  operate  throughout  any  transition  process.  To 
effectively  re-engineer  these  applications  DLA  must  possess  an  effective  CASE 
environment  of  forward  and  reverse  engineering  tools,  and  a  method  for 
transitioning  the  data  and  processes  after  the  re-engineering  is  accomplished. 

CASE  AND  OPEN  SYSTEMS 

The  I/S  industry  is  currently  divided  into  two  major  open  systems 

camps: 


^CASE  -  Computer  Assisted  Systems/Software  Engineering. 

JO 

'The  key  technology  in  the  industry  is  not  technology;  its  application  development”  -  Charles  Bachman. 

^^DSAC’s  PDF  records  do  not  match  Bachman’s  statistics.  DSAC  claims  70%  on  new  functions  (Projects)  which 
do  discrete  new  things  while  performing  only  30%  maintenance.  In  other  words,  Bachman  probably  counts  differently 
than  us. 


16 


5  April  1991 


DEFENSE  LOGISTICS  AGENCY 
INFORMATION  RESOURCES  MANAGEMENT  ENVIRONMENT 
VISION  AND  PRESCRIPTION 


POSIX**,  which  defines  a  standard  interface  for  operating 
systems,  currently  is  effectively  targeting  the  UNIX  operating 
system  as  its  base.  POSIX  is  DLA’s  ultimate  objective. 

Systems  Application  Architecture  (SAA)  is  the  IBM  open 
systems  concept.  In  order  to  demonstrate  its  commitment  to 
open  systems  IBM  has  announced  that  its  AIX  |  (a  POSIX 
compliant  version  of  UNIX)  |  will  fall  under  the  SAA  umbrella. 
IBM  has  also  announced  AD/Cycle  (Application 
Development/Cycle)  as  the  development  environment  under 
SAA.  Within  AD/Cycle  is  the  Repository  which  is  claimed,  by 
IBM,  to  meet  the  IRDS**  standard.  Repository  is  the  data  base 
designed  to  house  the  entire  scope  of  information  engineering 
metadata  from  business  systems  planning  through  code 
generation.  IBM  has  recognized  its  limited  ability  to  provide 
the  full  array  of  CASE  tools  needed,  but  has  instead,  made 
business  partner  arrangements  with  Knowledgeware,  Index 
Technology,  Developmate,  and  Synon.  These  corporations  have 
agreed  to  conform  to  the  Repository  format  with  their  CASE 
tools.  Many  other  CASE  tool  vendors  have  also  agreed  to  meet 
the  specifications  of  Repository  without  business  agreements 
with  IBM.  Thus;  Repository  provides  a  common  ground  for 
software  industry  competition  as  well  as  integration  for  a  large 
assortment  of  existing  and  potential  CASE  tools. 

DLA’s  CASE  STRATEGY 

Since  DLA’s  primary  application  systems  operate  in  the  IBM 
environment  and  current  consolidation  plans  will  considerably  extend 
that  environment  both  in  time  and  size,  it  is  imperative  that  DLA  adopt 
enablers  |  such  as  j  ADCycle/Repository  and  the  j  Cross  Systems 
Product  (CSP)  I  in  re-engineering  its  current  systems  into  portable  and 
inter-operable  systems.  TTiis  [would  allow  DLA  to  use  a  wide  variety 
of  Repository  compatible  CASE  tools  from  many  vendors  j  and  would 
provide  flexibility  for  applications  to  remain  on  the  IBM  environment 
and  to  move  to  POSIX  environments  during  the  re-engineering  phase. 
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EMERGING  TECHNOLOGIES 

Although  the  following  discussion  is  speculative,  there  are  a  number  of 
emerging  technologies^”  which  could  influence  DLA  during  the  next  5  years. 
Each  has  potential  for  inspiring  innovation  among  technical  and  functional 
proponents.  As  these  potentials  surface  and  are  evaluated,  the  technologies 
will  be  infused  within  the  DLA  environment.  Where  there  are  multiple 
choices  of  standards  for  a  particular  piece  of  technology,  DLA  will  adopt  those 
with  DoD  sponsorship.  Where  DoD  sponsorship  is  unspoken,  industry 
dominant  de  facto  standards  make  the  most  sense.  The  NIST  (National 
Institute  of  Standards  &  Technology)  has  recognized  the  value  of  industry  de 
facto  standards  j  ^'  |  as  opposed  to  independently  developed  government 
standards  which  |  are  sometimes  available  too  late  and  thus  |  receive  little  use 
or  support  from  industry  technology  developers.  Natural  competition  within 
the  I/S  industry  often  results  in  viable  de  facto  standards  which  NIST  has 
adopted  in  the  past  (e.g.  SQL)  and  which  serve  the  public  and  private  sectors 
well. 


OBJECT  ORIENTED 

Object  oriented  design  methodologies,  object  oriented  programming 
systems  and  object  oriented  data  base  systems  (OODMs,  OOPs, 
OODBs),  although  in  their  infancy  (pun  intended),  are  already 
indirectly  affecting  DLA.  The  indirect  effect  comes  from  the  many 
vendors  whose  software  DLA  uses.  Software  vendors  inevitably  claim 
that  their  packages  are  object  oriented.  Whether  or  not  they  re^ly  are 
is  debatable,  but  they  all  understand  the  marketing  value  of  the  words 
"object  oriented".  "00"  is  unlikely  to  directly  influence  DLA 
designers  for  the  next  two  or  three  years  simply  because  design  tools 
and  I.E.  methodologies  for  OO  are  still  immature,  there  are  no 
standards  (De  facto  or  official)  that  DLA  can  hang  its  hat  on,  and  it  is 
another  paradigm  shift  that  will  take  DLA  some  time  to  fully 


list  is  only  partial;  a  full  list  of  potential  technologies  would  be  exhaustive. 

^'structured  Query  Language  (SQL)  ;ind  X- Windows  are  examples  of  DeFacto  industry  standards  adopted  by  NIST . 
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understand  and  appreciate.  DLA,  as  well  as  most  practitioners  of  I/S, 
will  continue  to  develop  "Relational"  systems,  for  their  mainstream 
applications,  over  the  next  several  years.  However,  experimentation 
will  occur  in  some  areas,  particularly  graphical  interfaces  where  the 
"object"  orientation  is  most  obvious.  In  the  meantime,  the 
implementation  of  relational  systems  is  a  giant  step  in  the  right 
direction  and  contributes  towards  an  eventual  move  to  OO.  Eventually 
the  new  paradigm  will  extend  the  logical  content  of  an  entity  from  one 
containing  data  attributes  (Relational)  to  one  containing  both  data  and 
process  attributes  (Object  Oriented).  OO  promises  to  eventually 
increase  the  re-usability  levels  of  code  (re-usable  objects)  thus  reducing 
development  and  maintenance  costs.  DLA  will  watch  the  development 
of  this  technology  closely  to  assess  the  appropriate  time  for  its 
introduction^,  |  ^^  [ . 

IMAGE  PROCESSING 

Numerous  functional  requirements  are  emerging  within  DLA  which 
require  image  processing  capabilities”.  These  capabilities  must  span 
the  need  to  display,  store  and  transmit  images.  In  addition;  the  ability 
to  handle  compound  documents  will  be  necessary.  Compound 
documents  provide  the  integration  of  text,  graphics  and  images. 
Without  this  integration  much  of  the  practicality  of  image  processing 
may  be  lost. 


^^The  Supply  Support  Planning  &  Execution  (SSPE)  is  now  indicating  a  need  for  OODB  (Object  oriented  data  base). 

^^The  Object  Management  Group  (OMG)  has  received  standards  proposals  for  integrating  various  types  of  software 
objects  across  diverse  networks  and  platforms;  e.g.  ORB  (Object  Request  Broker)  which  is  the  mechanism  by  which 
objects  transparently  generate  and  receive  requests  and  responses.  -  LAN  Computing,  subject:  Object  Technologies 
Proposed  as  Standards,  March  26,  1991. 

”The  CTOL  (Cataloging  Tools  On-Line)  contract  with  the  Oracle  Complex  Systems  Corp.  contains  extensive  image 
processing  technology. 
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PAPERLESS  ENVIRONMENT 

Going  paperless,  j  which  is  probably  a  long  way  from  being  fully 
achievable! ,  is  a  combination  of  infusing  a  number  of  technologies, 
standards  and  procedures.  EDI,  |  CALS  | ,  Image  Processing,  Network 
Computing  and  standards  such  as  ANSI  X.12  (Data  Interchange 
Standard)  and  X.4(X)  (Electronic  Mail)  are  all  contributors.  {The 
staging  of  report  files  to  storage  for  on-line  demand  retrieval  instead  of 
printing  could  drastically  reduce  DLA’s  paper  requirements^*.  |  DLA 
is  aggressive  in  the  paperless  area  and  has  already  implemented  POPS 
(Purchase  Order  Processing  System),  SPEEDE  (SAMMS  Procurement 
by  Electronic  Data  Exchange)  and  EFT  (Electronic  Funds  Transfer). 
DLA  is  also  working  on  other  applications  and  an  intelligent  gateway 
called  LINX  (Logistics  Information  Exchange)  which  is  now  ready  to 
implement. 

NEUROCOMPUTING 

Sometimes  referred  to  as  "adaptive  systems".  Unlike  expert  systems 
which  use  rules,  a  neuro  system  can  determine  the  rules  through 
attempts  to  replicate  the  brain  structure  (learning).  For  the  time  being, 
neurocomputing  will  be  an  esoteric  buzzword  in  DLA,  but  will  be  a 
technology  which  DLA  will  monitor  and  seek  practical  applications. 

For  now,  here  are  some  more  buzzwords  to  amaze  your  friends: 

Neural  Networks  -  Software  simulations  of  neurocomputing 
containing  interconnected  processing 
elements. 

Neural  Chips  -  Still  under  development  |  for  business 
application  | .  Already  in  automobile 
diagnostic  systems. 


**DLA  produces  approximately  1  billion  pages  of  print  per  month.  We  certainly  can’t  be  looking  at  all  of  that. 
If  equated  to  book  form,  that  would  be  approximately  4  books/month  for  every  DLA  employee.  Quite  a  reading  club! 
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NEW  LOOK  MAINFRAMES 

There  is  a  tendency,  with  all  the  discussion  on  distributed  processing, 
distributed  data  bases,  client/server,  cooperative  processing  and 
network  computing,  for  many  people,  even  I/S  professionals,  to  look  at 
mainframes  as  dinosaurs.  V^ile  it  is  true  that  systems  will  have  quite 
different  architectures  in  the  future,  mainframes  are  not  likely  to 
disappear  from  the  scene".  A  Datamation  article^’  suggested  a 
likely  scenario  of  "New  Look  Mainframes": 


Powerframes  -  Characterized  by  the  ability  to  interface 

with  different  forms  of  databases,  these 
machines  have  parallel  processors  sharing 
an  organizationally  common  memory  and 
storage  hierarchy.  Their  chief  task  is  to 
regulate  the  flow  of  traffic  into  and  out  of 
those  databases  over  a  parallel  access 
input/output  structure  called  channel 
architecture. 


Serverframes  -  Serve  up  locally  shared  databases  to  a 

work-group  or  a  single  user. 

Clientframes  -  Home  of  all  new  applications  and  all 

human  interface  features,  these  machines 
eventually  will  allow  users  to  automatically 
generate  their  own  applications. 


Because  of  the  tendency  for  data  to  migrate  upwards  from  personal  to 
departmental  to  corporate  due  to  increasing  data  sharing  needs  it  is 
quite  likely  that  mainframes  will  act  as  relational  j  corporate  |  data 


"since  they  do  not  change  the  basic  systems  architectures  of  the  applications,  the  consolidations  will  also  add  to 
the  life  of  host  based  systems  which  are  currently  running  on  main-frames. 

Datamation  magazine,  June  IS,  1990,  page  188. 
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warehouses  in  the  future.  Other  roles  will  be  to  act  as  high  speed 
transaction  processors  and  network  managers. 

GRAPHICAL  USER  INTERFACES 

Graphical  User  Interfaces  (GUIs)  have  been  available  for  several  years. 
The  big  question  is  that  of,  which  one(s)  to  choose  for  DLA  usage. 
Currently  there  are  several  viable  contenders^*: 

Microsoft  Windows  3.0 

The  most  recent  entry  into  industry  competition;  and  probably 
the  most  widely  implemented.  3.0  has  taken  the  industry  by 
storm  with  its  Macintosh-like  interface  and  its  ability  to  extend 
the  life  of  MS/DOS  systems  by  its  extendibility  of  addressable 
memory  to  16  megabytes.  On  a  386  system,  it  also  provides 
virtual  memory  operation.  Windows  is  available  to  DLA 
through  the  DESK-TOP  III  contract  increasing  the  potential  of 
establishing  itself  as  a  practical  standard,  not  only  in  DLA  but 
in  other  DoD  activities. 

OS/2  Presentation  Manager 

IBM’s  bid  into  GUI  competition.  Since  it  requires  OS/2  it  is 
not  likely  to  become  a  DLA  standard  |  However,  if  CASE 
competition  were  to  result  in  a  DLA  acquisition  of  AD/Cycle, 
OS/2  would  be  selectively  installed  in  DLA’s  I.E.  activities. 
AD/Cycle,  among  other  things  such  as  DB2  on  the  mainframe, 
currently  requires  OS/2  on  its  work-stations. 


■30 

In  the  near-term,  the  most  likely  candidates  for  DLA’s  application  development  are  Microsoft’s  Windows  3.0  for 
DLA’s  DOS  environment  and  X-Windows  for  the  UNIX  environment. 

^^Microsoft  is  rumored  to  be  working  on  a  New  Technology  (NT)  kernel  for  OS/2  that  would  support  Windows, 
Presentation  Manager  and  POSIX.  If  this  is  true,  OS/2  (because  of  POSDC  compliance)  would  be  acceptable  to  DLA.  - 
LAN  Computing,  subject:  Standards  Watch,  March  26,  1991. 
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Standards  Organization’s  GUIs 

There  are  several  standards  organizations  sponsoring  GUIs 
I  which  are  based  upon  the  same  X-Windows','*®  platform  | , 
Among  these  GUIs,  |  which  differ  only  in  their  "Look  and 
feel" I,  are: 

Open  System  Foundation’s  Motif 
UNIX  International  Inc’s  Open  Look 
X-Windows 

INTEGRATED  SERVICES  DIGITAL  NETWORK  (ISDN) 

ISDN  offers  an  all-digital  service  which  reduces  errors  and  cost  and 
provides  the  capability  of  carrying  many  networks  over  a  single  link. 

It  allows  the  integration  of  voice,  data,  and  image  services  through 
twisted-pair  telephone  wire.  The  ability  to  access  separate  networks 
through  a  single  plug  in  the  wall  has  obvious  advantages  to  subscribers. 
Some  of  the  ISDN  services  such  as  broadband  and  numbering  and 
addressing  for  the  U.S.  market  may  not  be  available  until  after  1992 
when  the  CCITT^*  four  year  study  period  is  completed. 

e.  ORGANIZATIONAL  ENVIRONMENT 

One  can  determine  the  number  of  Information  Processing  Centers  (IPCs)  that  are 
necessary  simply  by  considering  an  IPC  as  a  utility  for  processing  information 
systems  applications.  That  approach  would  base  the  determination  of  the  number  and 
location  of  sites  on  the  number  and  sizes  necessary  to  perform  the  workload  while 
providing  a  certain  amount  of  physical  separation  and  redundancy  for  the  level  of 
security  desired.  There  is  nothing  wrong  with  this  approach;  |in  fact  it  is  the 
ultimate  DLA  goal  for  operations! .  However;  DLA’s  Conceptual  Functional 
Requirements  identified  five  Business  Areas  which  were  reduced  to  four  in  the  DLA 


^^ortions  of  the  X-Windows  system  specifications  were  adopted  as  a  Federal  Processing  Standard  in  May  1990. 
^'international  Consultive  Committee  for  Telephone  and  Telegraph. 
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Strategic  Plan.  These  areas  now  are  |  Acquisition  Services,  Material  Management, 
Distribution  Services  and  Corporate  Support).  Information  Resources  Management  is 
a  critical  factor  in  the  success  of  all  the  Business  Areas  and  may  be  considered  |  as  if 
it  were)  a  Business  Area  in  its  own  right,  thus  increasing  the  count  back  to  five|^^| . 
This  paper  prescribes  an  IPC  jas  the  operational  center)  for  each  of  the  major 
business  areas  as  an  appropriate  way  to  delineate  workload.  This  gives  each  IPC  a 
personality  and  potentially  a  greater  feeling  of  responsibility  for  an  area  of  DLA’s 
mission,  rather  than  the  "push  a  button,  grab  a  banana  approach"  that  the  non-distinct 
IPCs  would  foster.  }This  association  is  considered  necessary,  at  least  temporarily,  as 
a  transition  step  to  the  utility  approach  where  IPCs  have  no  specific  DLA  functional 
mission  identity. } 

To  the  extent  possible,  application  development  activities  )  will }  actually  be  co-located 
with  representative  clusters  of  end-users  in  order  to  facilitate  user  participation  in 
information  engineering  and  prototyping  for  application  development. 

Since  the  prescribed  methods  of  this  paper  focus  on  keeping  data  separate  from 
applications,  a  valid  option  would  be  to  include  the  application  development  groups  as 
an  organizational  part  of  the  PSE’s  whose  functions  they  automate.  Although  this  is 
not  currently  being  prescribed,  it  could  become  a  viable  option  after  the  re-engineered 
environment  is  normalized }  ^^ } . 

AUTHORITIES  AND  RESPONSIBILITIES 

DLA’s  information  resource  management  organizations  provide  information 
services  to  enable  the  performance  of  the  business  processes  defined  by  DLA’s 
Principal  Staff  Elements  (PSEs).  These  business  processes  are  executed  by 
end-users  within  DLA  and  by  many  outside  activities  that  are  recipients  of 
DLA’s  functional  supply  and  other  logistics  services.  In  order  for  DLA’s 


^^IRM  is  the  main  business  area  of  the  DLA  IRM  organization,  although  IRM  is  not  a  DLA  business  area. 

^^Theoretically;  when  all  enterprise  information  engineering  metadata  from  business  objectives,  functions  and  entities 
through  detail  action  diagram  level  logic  blocks  are  housed  and  maintained  in  a  common  repository,  application 
development  and  revision  will  amount  to  the  changing  of  business  rules  and  procedures  and  generating  new  business 
foundation  code  modules. 
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information  system  service  organizations  to  properly  interpret  the  business 
needs  of  the  PSE’s,  develop  the  enabling  information  services,  and  to 
effectively  manage  and  operate  the  information  systems,  it  contains 
headquarters,  design  and  operational  elements,  'hiese  elements  are  assigned 
unique  responsibilities  to  assure  that  the  services  needed  are  provided  and  that 
they  are  provided  in  an  efficient  and  cost  effective  manner. 

HEADQUARTERS  ELEMENT 

The  headquarters  unit  is  expected  to  interface  with  the  PSEs  to 
determine  their  functional  needs  and  to  communicate  these  functional 
needs  to  design  units  for  design  and  implementation.  The  headquarters 
must  provide  policy  guidance  and  monitor  design  and  operational 
activity  to  assure  that  the  Agency’s  information  resources  are  designed 
and  operated  effectively  and  economically  and  that  they  meet  the 
business  needs  of  the  PSEs.^ 

DESIGN  ELEMENT 

The  design  element  interfaces  directly  with  the  end-users  to  meet  their 
operational  needs  while  performing  detailed  information  engineering  of 
the  functional  data  and  process  needs  of  the  PSEs.  The  design 
elements  develop  operational  information  systems  and  integrate  them 
into  other  systems  in  operation  at  each  of  the  information  systems 
operational  elements. 

OPERATIONAL  ELEMENT 

The  operational  elements  manage  and  operate  the  information  systems 
resources  assigned  to  them  in  the  most  cost  effective  way  possible  to 
satisfy  the  demands  of  the  end-users. 


'^Management  indicators  such  as  the  information  resource  costs  by  site  for  processing,  requisitions,  material  release 
orders,  contracts,  etc.  and  customer  service  satisfaction  levels  would  be  major  factors  in  determining  IRM’s 
cost/effectiveness. 
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INFORMATION  FLOW  REQUIREMENTS 

In  order  that  the  three  types  of  information  system  services  elements  operate  as 
an  effective  team  in  the  spirit  of  Total  Quality  Management  (TQM)  it  is 
necessary  to  define  the  critical  interfaces  and  information  flow  requirements 
that  must  pass  between  them.  Failure  to  interface  and  to  pass  the  necessary 
information  may  effect  the  efficiency  and  cost  effectiveness  of  DLA’s 
information  systems  services.  Enel.  10  reflects  the  necessary  interfaces  and 
data  flows. 

PRESCRIBED  ORGANIZATIONAL  STRUCTURE  (See  end.  1) 

The  Corporate  IRM  Official  would  have  the  ultimate  responsibility  for  all 
DLA  information  resources.  All  IRM  organizations  would  report  to  this 
official.^* 

CORPORATE  IRM  POLICY  GROUP  (Headquarters  Elem.) 

A  Corporate  IRM  Policy  Group  would  be  responsible  for  all  IRM 
policy.  This  responsibility  would  include  overall  IRM  Comptroller 
authority.  In  addition  the  IRM  Policy  Group  would  be  the  first-line 
interface  with  PSEs  for  determining  and  recording"  overall  DLA 
Business  Requirements.  This  group  would  be  physically  co-located 
with  the  Corporate  IRM  official  and  the  DLA  Principle  Staff  Elements 
(PSEs). 

CORPORATE  I.E.  &  TECHNOLOGY  CENTER  (Design  Elem.) 

This  center  would  provide  all  information  technology  to  the  functional 
IPCs  and  other  ITFs.  It  would  provide  the  Corporate  Mutual  Interest 


"Headquarters,  Design,  and  Operational  sites  will  be  collectively  referred  to  as  Information  Technology  Facilities 
(ITFs)  in  this  paper. 

"aII  business  objectives,  strategies,  requirements,  etc.  would  be  recorded  in  the  DLA  Enterprise  Model  Repository. 
The  same  repository  would  be  utilized  by  all  IRM  organizational  elements.  Thus,  the  repository  would  retain  all  of  the 
enterprise’s  information  system  metadata  from  the  highest  level  business  objectives  through  action  flow  information 
needed  for  code  generation.  All  systems  would  be  maintained  by  modifying  this  repository  and  generating  new  code  as 
necessary. 
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Back-up  (MIBS)  and  LE.  environments  for  all  IPCs.  It  would  develop, 
administer  and  control  the  integrity  of  the  Corporate  data  base  (the 
physical  data  base  may  be  deploy^  at  the  IPCs  as  appropriate)  1  | . 

It  would  develop,  administer  and  control  the  Corporate  wide-area 
communications  networks.  It  would  be  the  central  design  activity  for 
all  information  system  applications,  j  even  though  |  to  the  extent 
possible,  application  development  personnel  would  be  co-located  with 
clusters  of  end-users  to  facilitate  user  participation  in  application 
development. 

I  In  short;  this  center  creates  and  manages  the  Agency’s  lego  blocks 
(data,  process,  technology).  It  also  provides  support  and  control  for 
the  Agency’s  shared  resources  (data  base,  communications  network, 
backup  environment)  and  performs  standard  application  development,  j 
(See  enclosure  2). 

INFORMATION  PROCESSING  CENTERS  aPCs)  (Opns  Elem.) 

The  IPCs  would  provide  all  operations  and  end-user  support  to  mission 
function  and  DLA  administrative  support  applications.  The  following 
IPCs  would  be  established.  (See  enclosure  3) 

Corporate  Administrative  Support 
Material  Management 
Distribution  j  Services  | 

Acquisition  j  Services! 

Corporate  I/S  Development  &  MIBS"*,* 


"^The  ultimate  integrity  of  data  is  controlled  by  the  functional  proponents  (PSEs)  through  meticulous  application 
of  operational  business  transactions.  IRM  however,  is  the  custodian  and  must  assure  the  safeguarding  and  physical 
integrity  of  the  data  base. 

"*The  notion  of  forming  an  IPC  for  the  1/S  development  operational  environment  was  first  put  forward  by  J.  Froehle 
and  E.  Troupe  of  DSAC  during  a  brief  to  DLA-Z.  The  notion  treated  1/S  Development  as  any  other  operational 
application  and  opened  the  possibility  for  DLA-Wide  sharing  of  development  tools  (repository,  languages,  etc.).  Thus 
only  one  Agency  license  for  development  tools  would  be  necessary,  regardless  of  where  the  developers  may  be. 
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3.  MIGRATION  OPTIONS 


DLA,  like  virtually  every  other  major  organization  that  has  developed  information  systems 
over  several  decades,  has  tended  to  create  application  data  bases,  not  subject  data  bases. 

This  means  that  DLA  has  many  data  bases  and  files  that  are  tailored  to  a  specific 
application’s  needs.  Efficient  yes,  for  that  application;  but  the  next  application  in  turn  has  its 
own  data  base,  and  so  on.  This  can  and  has  resulted  in  overall  data  redundancies  and 
inefficiencies  in  the  use  of  data  resources.  DLA  is  serious  about  sharing  data  across 
applications,  and  is  developing  concepts  and  facilities  for  transitioning  its  applications  and 
data  bases. 

a.  CHALLENGES  (See  figure  1) 

The  difficulty  in  transitioning  from  application  to  subject  data  bases  has  been  the 
nemesis  of  many  IRM  organizations.**’  A  partial  reason  for  this  difficulty  is  the 
change  from  the  one-to-one  correspondence  of  application-to-data  to  a  many-to-many. 
This  means  that  straight  conversion  lines  can’t  be  drawn  from  the  old  data  bases  to 
the  new  ones.  If  the  applications  are  to  be  re-aligned  also,  one  is  forced  to  make  the 
decision  of  converting  data  bases  first,  or  conversely  applications  first*.  All-at-once 
conversion  approaches  generally  are  discarded  up  front  because  they  are  usually  too 
big  to  handle,  although  one  approach  called  ANDES  (A  New  DLA  Environment 
Seed)"  rationalizes  a  means  of  making  a  fresh  start  feasible  |  without  heavy  bridging 
requirements  | .  |  Excluding  the  ANDES  approach  | ,  either  choice;  data  first  or 
application  first  implies  a  need  for  bridging  from  the  old  to  the  new  systems  that  have 
not  been  fully  converted.  These  bridges  can  prove  to  be  costly  and  long-lived 
legacies. 

In  any  case,  even  if  a  decision  were  made  for  one  general  transition  approach  over 
the  other  (data-first  vice  application-first)  it  is  unlikely  that  all  data  or  applications 


‘’’"The  seamy  side  of  I/S  is  imprecise,  inelegant,  and  difficult  to  describe,  but  it  addresses  the  most  serious  problem 
facing  many  companies.'  -  Roger  Buchanan;  in  Explain  Magazine  pp  19-22  article  titled  'CASE  TOOLS:  DATA 
MIGRATION',  date  of  issue  unknown. 
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could  be  transitioned  simultaneously.  All-of-the-data  or  all-of-the-applications  j  in 
one-fell-swoop  I  would  still  be  too  much. 


b.  GENERAL  APPROACHES 

CROSS  MODEL  RESOLUTION  APPROACH  (See  enclosure  4) 

DLA  has  initiated  a  research  and  development  project’'  to  acquire  and/or 
develop  a  reasonable  means  by  which  to  facilitate  the  transition  of  DLA’s 
information  systems  and  data  bases  to  target  designs.  DLA  can  be  certain  that 
the  target  data  models  (when  completed)  will  not  totally  match  real-world  data 
bases  for  some  period  of  time,  therefore  DLA  intends  to  bring  about  a 
technical  facility  that  will  provide  cross-model-resolution.  In  other  words, 
DLA  will  initiate  re-engineering  and  conversion  projects  which  reference  new 
target  data  models  even  though  the  real-world  data  has  not  yet  been  converted. 
The  cross-model-resolver’s  (XMR)  function  would  be  to  provide  the  new 
target  view  of  data  to  the  applications  and  end-users  while  delivering  data  from 
the  old  file  and  data  base  structures  transparently.  The  actual  data  will  then  be 
gradually  migrated  over  to  the  target  structures,  eventually  eliminating  the 
need  for  the  XMR. 

CROSS  MODEL  SERVICE  AND  TECHNICAL  REQUIREMENTS 
An  acceptable  Cross  Model  Resolver  facility  must  meet  the  following 
minimum  requirements: 

The  XMR  must  provide  these  services: 

TARGET  MODEL  VIEW:  Provide  for  end-user  and  computer- 
to-computer  client  viewing  of  the  data  model  and  delivery  of 
real-world  data  to  be  in  the  target  model  view. 

TRANSPARENT  RESOLUTION:  Perform  transparent  cross 
model  resolution  from  target  to  existing  data  models. 

The  XMR  must  satisfy  these  technical  requirements: 
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ON-LINE  DATA  MODELS:  Provide  on-line  storage,  access 
and  maintenance  of  data  models  (Entity  Relationship  Diagram 
metadata)  for: 

Target  data  models. 

Models  of  existing  data  structures. 

SQL  SERVER:  Act  as  an  SQL  (Structured  Query  Language) 
server  to  a  client.  A  client  may  be  an  end-user  workstation 
SQL  interface  or  an  application  passing  SQL  through  an  inter¬ 
program  call. 

METADATA  MODEL  STORAGE:  Store  the  data  models  in 
compliance  with  the  IRDS  (Information  Resource  Dictionary 
System)  standard.  See  DODD  5(X)0. 1 1  "DoD  Data 
Administration".  If  the  IRDS  standard  does  not  cover  the 
necessary  formats,  the  IBM  AD/CYCLE  Repository  metadata 
formats  may  be  considered  for  use.  This  would  require  review 
and  approval  by  DLA-ZI  (Systems  Integration  Division). 

PORTABLE  LANGUAGE:  Be  developed  in  a  portable  language 
such  as  "C"  or  "Ada".  Careful  attention  must  be  paid  to  the 
economics  and  supportability  of  the  choice. 

PORTABLE  ENVIRONMENT:  Develop  shared  server 
executables  for  the  POSIX  environment  and  the  client 
workstation  executables  for  MS/DOS  environment. 

Development  of  client  workstation  executables  for  POSIX  is  not 
mandatory  at  the  current  time  but  will  become  a  requirement 
later. 

DISTRIBUTED  PROCESSING:  Be  capable  of  operating  in  a 
distributed  processing  mode,  either  in  a  workload  balancing  or 
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distributed  transaction  mode,  or  both,  to  eliminate  capacity  and 
performance  constraints  of  a  single  box.  See  enclosure  12. 

METADATA  MODEL  MAINTENANCE:  Provide  a  means  of 
maintaining  the  data  models  as  changes  are  necessary.  The 
models  will  change  as  the  target  fluctuates  and  as  real-world 
data  is  migrated  to  data  bases  representing  the  target  models. 

DECISION  STORAGE;  Provide  for  the  storage  and 
maintenance  of  management  decisions  regarding  the  resolution 
of  illogical  data  model  conditions  such  as,  which  data  attributes 
(elements)  to  use  when  the  attributes  are  located  redundantly 
(with  perhaps  different  values)  in  multiple  separate  existing 
files/data  bases. 

ON-LINE  MODEL  GUIDE:  Provide  for  observation  of  the 
target  data  model(s);  either  on-line  or  through  hard-copy  user 
guide  form.  On-line  should  be  considered  as  the  primary  mode 
of  viewing.  The  on-line  viewing  of  the  target  model  must  be 
color  coded,  e.g.  "Green"  would  indicate  that  data  is  available 
from  the  real-world  through  XMR,  "Yellow"  would  indicate  that 
data  is  available  but  that  performance  penalties  may  be  expected 
because  of  strong  model  incompatibilities,  "Red"  would  indicate 
that  the  data  is  unavailable  in  the  real-world  either  because  it 
doesn’t  exist  or  because  it  is  on  unaccessible  media  such  as 
magnetic  tape  or  printed  paper. 

SHARED  EXECUTABLES;  Locate  the  executable  for  the 
server  portions  of  the  XMR  in  shared  (shared  by  multiple 
clients)  facility(s).  This  executable  would  perform  functions 
such  as  accessing,  analyzing,  and  resolving  differences  from  the 
target  and  the  real-world  data  models,  network  gateways, 
accessing  and  formatting  real-world  data  in  accordance  with 
SQL  commands  received  from  clients,  delivering  data  requested 
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by  SQL  to  the  client,  etc.  It  would  be  acceptable  for  this 
portion  of  the  XMR  to  co-reside  with  other  applications. 

END-USER  EXECUTABLES:  Locate  the  human  end-user  client 
executable  in  the  end-user  workstation  (e.g.  Presentation 
management,  interactive  SQL  developer,  etc.). 

OTHER  EXECUTABLES:  Locate  other  client  executables  such 
as  functional  application  server  inter-program  call  mechanisms 
in  the  processor  box(s)  of  the  client  application. 

SAVED  SQL:  Provide  means  for  end-users  to  save  and  re- 
execute  SQL  that  they  have  entered. 

TECHNOLOGY  INTEGRATION:  Comply  with  technology 
integration  policies  and  objectives  of  the  DLA  IRM  Near-Term 
Plan  and  other  documents  referenced  by  the  plan. 

NON-TECHNOLOGY  FACTORS  CRITICAL  TO  SUCCESS  OF 
XMR 


COMMITMENT  TO  STRATEGY:  Once  the  cross  model 
resolver  or  other  transition  strategy  is  proven  to  be  viable,  a 
DLA  commitment  to  that  concept  and  strategy  would  make  it 
achievable. 

DATA  ADMINISTRATION:  A  serious  data  administration 
function  is  necessary  to: 

a.  Develop  target  data  model(s). 

b.  Develop  "real  world"  data  model. 
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c.  Develqp  and  execute  a  strategy  (sequence  of  data 
base/data  attribute  moves)  for  transitioning  from  the 
target  to  the  real  world  models. 

d.  Maintain  the  target  and  real  world  models  throughout  the 
entire  transition. 

FRRSH  START  APPROACH  (See  figures  2,  3  and  4) 

The  following  discussion  rationalizes  a  means  of  making  a  fresh  start  in 
developing  new  systems  without  the  legacies  of  the  past. 

THE  MOST  DIFFICULT  THING  ABOUT  MODERNIZATION  IS 
THE  TRANSITION  -  From  an  information  systems  point  of  view  the 
real  significance  of  the  transition  is  a  concurrent  realignment  of 
computer  applications  and  data  architectures.  The  migration  from 
DLA’s  application  data  base  environment  to  a  subject  data  base 
environment  is  not  possible  through  a  one-to-one  conversion  process 
since  the  correspondence  between  data  and  applications  will  no  longer 
be  a  one-to-one.  Realignment  of  applications  at  the  same  time  further 
complicates  the  transition.  From  a  broader  perspective,  DLA 
organizational  and  functional  changes  |  could  j  create  even  further 
complications. 

CHANGING  IN  PLACE  IS  DIFFICULT  -  The  inertia  of  existing 
organizations,  functional  and  systems  methodologies  will  create  a 
resistance  to  change  that  should  not  be  ignored.  Virtually  any  concept 
of  migration  requires  the  building  of  bridges  connecting  the  old  to  the 
new  until  transformation  has  been  completed.  Most  of  the  bridges  will 
be  data  bridges  designed  to  keep  old  and  new  data  bases  in 
synchronization.  Whatever  they  are,  bridges  add  to  complexity  and 
may  create  |  additional  legacies  |  that  may  still  be  around  for  decades. 
Any  attempt  to  change  in  place  will  result  in  compromises  between  the 
old  and  new  which  may  result  in  a  condition  where  the  new  never 
I  quite  I  reaches  the  goals  for  which  it  was  to  be  designed. 
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A  NEW  ENVIRONMENT  UNCONSTRAINED  BY  THE  OLD  IS 
POSSIBLE  -  In  order  to  believe  that  modernization  is  feasible  to 
implement,  one  must  have  confidence  that  the  functionality  described  in 
j  the  business  |  requirements  can  be  developed  anew.  Because  of 
realignment  of  data  and  applications,  old  code  is  not  directly 
transferable.  Even  if  there  were  no  realignment,  the  systems  |  will  j 
need  re-engineering  before  they  become  totally  unmaintainable.  With 
recent  developments  in  systems  design  and  development  technology  it 
can  now  be  considered  acceptable  to  throw  away  (or  reverse-engineer 
to  an  acceptable  base)  old  code  investments  and  re-invest  in  forward  re¬ 
engineering  for  the  long-term  benefit  of  the  Agency.  Recoding  is 
further  simplified  by  the  diminishing  need  to  identify  all  of  the 
functionality  hidden  in  "Unique  Code"  residing  undocumented 
throughout  the  Agency.  As  appropriate,  end-user  programming  will 
take  up  the  slack  left  by  the  lost  undocumented  functionality  of  the 
"Uniques"!^",'. 

A  NEW  DLA  ENVIRONMENT  SEED  -  A  migration  course  that  may 
virtually  eliminate  |the  need  for{  bridges  and  their  inherent  costs, 
while  at  the  same  time  reducing  overall  transition  risk  to  a  minimum,  is 
the  creation  of  a  seed  activity  for  the  future  DLA.  This  seed  would  be 
given  its  own  mission  and  functions  and  would  in  effect  be  a  miniature 
version  of  DLA  operating  under  rules  similar  to  Model  Installations 
Program  rules.  The  seed  would  require  a  computer  site  in  which  the 
future  applications  and  data  bases  would  be  developed  and  run  in 
miniature  until  all  of  the  functionality  required  by  DLA  is  in  operation. 
The  seed  could  at  first  be  given  a  few  stock  classes  to  manage  (a  few 
hundred  items)  from  a  relatively  straightforward  commodity  such  as 
electronics.  It  would  also  be  given  some  small  category(s)  of  contracts 
to  administrate.  Personnel  from  the  PLFA’s  would  be  designated  as 
part  of  the  seed  environment.  They  could  either  work  from  their 


of  DLA ’s  so-called  'Uniques"  are  data  extracts  from  existing  files.  End-user  programming  through  friendly 
interfaces  (which  generate  SQL  under  the  covers)  should  handle  most  of  these  needs.  Care  must  be  taken  however  to 
assure  that  these  uncontrolled  requests  do  not  overload  the  environment. 
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present  locations  or  be  provided  office  space  close  to  the  seed.  They 
would  perform  their  normal  (or  redesigned)  functions  such  as  supply 
control  analysis  and  contract  administration  through  the  new  seed 
system  j  | .  As  the  seed  achieves  success  in  managing  its  mission  it 
would  be  expanded  to  include  new  classes  which  would  include  unique 
problems  from  such  areas  as  fuels,  perishables  and  more  complex 
contracts.  This  concept  would  substantially  reduce  overall  risk  and 
start-up  costs  and  permit  expansion  as  budget  allows. 

SOWING  THE  SEEDS  -  Once  an  information  systems  seed  is  fully 
operational  it  can  either  become  an  IPC  or  be  exported  to  the  IPCs. 


^'Because  the  ANDES  approach  is  not  constrained  by  the  legacies  of  the  past,  new  paradigms  such  as  the  "Product 
Manager*  concept  would  be  much  easier  to  implement.  The  "Product  Manager*  is  the  embodiment  of  several  legacy 
positions;  Engineer/Cataloger,  Item  Manager,  and  Buyer.  The  same  considerations  are  true  in  implementing  the  new 
distribution  paradigm  of  "Just-In-Time*  as  appropriate  to  the  commodities  being  managed. 
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Figure  1  Migration  Challenge 


Figure  3  ANDES  Foundation 


Figure  2  ANDES  Strategy 
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4.  ALTERNATIVE  IMPLEMENTATION  STRATEGIES 


Executive  level  plans  for  alternative  implementation/migration  strategies  are  presented  here. 
The  alternatives  have  far  more  similarities  than  dis-similarities.  Both  assume  a  normal 
resumption  of  activity  after  the  current  IPC  consolidations  and  "Interim  Standard  Systems" 
implementations  before  they  would  begin.  Both  are  critically  dependent  upon  the  full 
information  engineering  of  data  and  processes  to  determine  subject  data  bases  and  foundation 
application  modules.  Both  include  the  use  of  CASE,  the  inclusion  of  IRM  business  entities 
in  the  corporate  data  base,  and  so  on.  While  the  first  alternative  is  critically  dependent  upon 
the  existence  of  cross  model  resolution  facilities,  the  second  could  use  but  would  not  be 
dependent  upon  cross  model  resolution.  A  third  alternative  is  to  withdraw  plans  for  sharing 
data  by  way  of  common  data  models  and  subject  data  bases. 

a.  CHANGE  IN-PLACE  (CIP)  (See  enclosure  7) 

The  first  alternative  describes  a  scenario  whereby  the  envisioned  IRM  environment  is 
achieved  through  a  gradual  process  of  re-engineering  the  applications  and  data  bases 
until  the  entire  transition  is  completed.  Since  the  strategy  evolves  the  DLA  IRM 
environment  in-place,  it  will  be  referred  to  as  the  CIP  (Change-In-Place)  strategy. 

This  strategy  requires  heavy  use  of  cross  model  resolution  facilities. 

b.  A  NEW  DLA  ENVIRONMENT  SEED  (ANDES)  (See  end  8) 

The  second  strategy  actually  creates  a  new  environment  beyond  the  existing  DLA 
environment.  DLA  mission  functions  would  gradually  be  transferred  to  the  new 
environment  as  it  grows  in  capability  to  accept  them.  This  alternative  will  be  referred 
to  as  the  ANDES  (A  New  DLA  Environment  Seed)  strategy.  This  strategy  may  be 
supplemented  by  the  use  of  cross  model  resolution  facilities.  |  For  example;  cross 
model  resolution  may  be  used  to  provide  early-on  MIS-like  access  to  existing  data 
structures  on  a  query-only  basis.  This  would  have  the  effect  of  satisfying  pent-up 
demands  for  information  from  existing  files  while  the  new  systems  are  being 
developed  under  ANDES.  This  may  reduce  some  pressure  on  the  ANDES  efforts  and 
may  help  to  thwart  otherwise  hasty  decisions  that  could  reduce  the  effectiveness  of  the 
new  systems.  | 
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c.  CHANGE  OF  PLANS  (COP  OUT) 

A  third  alternative  is  to  withdraw  plans  for  the  sharing  of  data  by  way  of  common 
data  models  and  subject  data  bases  as  specified  in  DLA’s  CFR  and  Strategic  Plans. 
This  alternative  would  mean  that  data  could  be  shared  across  incompatible  and  often 
redundant  data  models  by  way  of  communications  gateways  into  non-integrated 
applications.  In  the  worst  case  it  could  mean  that  no  attempt  at  data  sharing  will  be 
made,  and  that  applications  would  continue  on  with  their  insular  use  of  data.  This  is 
a  status  quo  alternative.  Since  DLA’s  requirements  and  objectives  state  the  Corporate 
Data  objectives  (single-image),  the  requirements  and  objectives  should  be  chang^  if 
this  option  is  decided  upon. 
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5.  FUTURE  VERSIONS  OF  VISION  AND  PRESCRIPTION 


j  Because  of  its  wide  scope,  the  potential  material  that  could  be  covered  in  this  paper  is 
virtually  infinite.  In  order  that  this  version  be  delivered  for  review  and  comment,  an 
arbitrary  stopping  point  was  established.  Otherwise  one  could  go  on  writing  forever  with  no 
conclusion.  This  version  establishes  the  current  official  IRM  policies  and  directions.  Future 
policy  and  direction  changes  may  require  revisions.  Comments  and  suggested  expansions 
received  on  this  version  will  be  evaluated  and  incorporated  to  the  extent  possible  and  new 
versions  will  be  published  as  necessary.  The  Director,  DLA  Office  of  Information  Systems 
and  Technology  will  make  final  determinations  on  policy  and  direction  changes.  These 
decisions  will  take  the  form  of  re-endorsement  of  later  versions  of  this  paper.*^  | 

Some  additional  topics,  inserts  and  enhancements  to  this  paper  are  already  being  considered 
and  researched.  This  section  will  act  as  a  holding  place  for  these  random  thoughts.  The 
thoughts  may  find  their  way  into  future  versions  of  this  paper,  or  better  yet,  into 
implementations  1 1 .  For  example; 

Include  a  discussion  and  chart  depicting  IRM  activities,  PSEs  and  end-users  sharing  a 
corporate  repository  to  describe,  develop,  generate  and  maintain  application  systems. 
Talk  about  how  all  life  cycle  development  (Requirements,  analysis/design, 
development,  build  and  test)  becomes  maintenance  of  the  repository. 

Discuss  the  need  for  a  single  point  of  entry  for  transactions  into  DLA  with  automatic 
routing  to  appropriate  sites,  facilities  and  applications.  |  Also  discuss  how  data  should 
always  be  entered  into  the  system  at  the  point  of  creation.  | 

Discuss  capacity  management  in  the  client/server  environment  as  opposed  to  the 
host/centered  environment.  Client/server  opens  up  opportunities  for  intelligent 
modular  upgrades  without  the  need  for  full  system  replacements  each  time  capacity  is 
outgrown.  This  would  make  the  need  for  long  range  capacity  projections  less  critical. 


*^Yogi  Berra  also  said;  "When  you  come  to  a  fork  in  the  road  -  Take  it". 
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Discuss  the  use  of  reverse  engineering  as  a  supplement  to  re-engineering.  Old  data 
bases,  in  particular,  may  be  reverse  engineered  then  forward  engineered  to  the 
corporate  data  model.  Old  applications  are  more  difficult  to  reverse  engineer,  but 
there  is  potential  there  also. 

Discuss  what  the  consolidation  environment  will  probably  bring  and  how  it  may  help 
in  DLA’s  re-engineering  phase.  Systems  Application  Architecture  (SAA), 

System/390  era  hardware  technology,  applications  running  in  PRISM  or  PRISM-Like 
split  system  environments. 

Discuss  data  distribution.  Personal  data  on  workstations;  departmental  data  on  LAN 
SQL  servers;  corporate  data  on  WAN  SQL  servers.  Data  distribution  is  driven  by  the 
need  to  share.  When  several  people  need  to  share  personal  data  it  moves  up  to 
departmental;  when  several  departments  need  to  share  departmental  data  it  moves  up 
to  corporate. 

Include  a  Venn  diagram  of  organizational  interfaces  with  an  affinity  analysis 
determination  to  aid  in  the  placement  of  personnel. 

Include  an  analysis  of  specific  migration  tools  needed  to  enable  DLA  to  adjust  to  the 
new  paradigms. 

Discuss  the  potential  for  hypermedia  technology  in  the  emerging  technologies  section. 

Include  more  discussion  on  the  enterprise  model;  what  it  is,  how  it  is  used,  what 
value  it  adds.  Visual  abstraction  of  the  enterprise.  Manage  the  enterprise  with  the 
model. 

Include  an  analysis  of  the  type  of  people  needed  to  staff  the  various  IRM  elements. 
E.g.  Headquarters  is  not  a  good  place  to  develop  inexperienced  IRM  people.  They 
need  to  be  experienced  when  they  start  in  headquarters  or  be  detailed  to  field  jobs  as 
headquarters  interns. 
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Include  more  discussion  on  expert  systems  -  Expert  system  is  the  co-pilot;  operator  is 
the  pilot.  In  other  words,  the  expert  system  is  only  as  good  as  the  pilot’s  talent, 
training  and  experience.  Remember  that  when  CASE  is  used. 

Take  Zachman’s  framework  and  add  players  at  the  various  levels.  Data  analysts, 
systems  analysts,  database  administrators,  programmers,  etc. 

Expand  the  discussion  on  organizational  structure  to  more  detail  on  responsibilities  of 
various  elements.  Include  explanation  of  the  MIBS  (Mutual  Interest  Backup  System); 
how  it  will  work,  how  it  will  be  managed. 

I  Determining  how  and  when  to  incorporate  comments,  especially  when  conflicting  comments 
from  various  organizations  are  received,  is  never  easy.  Hopefully  justice  has  been  done; 
however  the  consequence  of  some  comments  received  on  the  Strawman  may  only  be  partially 
addressed  but  not  fully  decided  in  this  version.  Although  this  version  represents  DLA’s 
current  official  position,  the  following  comments  may  elicit  future  changes: 

From  DLA-L  -  "We  didn’t  see  the  total  integration  of  the  IPCs,  ISCs  and  the  ICs 
discussed  in  this  paper.  The  direction  that  has  been  set  forth  in  DMRD-924  (IPC  & 
CDA  consolidation)  will  determine  all  DoD  components  future  IRM  environments. 
This  vision  paper  must  reflect  the  changes  that  will  be  made  in  DLA’s  IRM  Program 
including  the  AIS  Executive  Agent  Charters. " 

From  DSAC  -  ‘"Organizational  Environment"  -  Nonconcur  with  the  strict 
endorsement  of  "functional  IPCs".  Economies  dictate  that  DoD  and  DLA  take  a 
"utility"  approach  such  as  was  defined  in  "magnet  centers".  The  "account  manager" 
concept  should  be  employed  to  address  application  developer  and  end-user 
relationships.  This  is  also  true  for  production  system  operations  activities.  The  entire 
organizational  environment  including  the  interrelationships  between  HQ,  Technical 
Services  Organizations,  Development  Activities,  IPCs,  PSEs  and  end-users  needs  to 
be  addressed  very  quickly.’ 

From  DSAC  -  "Migration  Options  -  Another  migration  option  may  be  to  establish  the 
"information  processing"  concept  which  migrates  all  data  to  on-line  information 
process  and  decision  support  systems  consisting  of  new  relational  subject  area  data 
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bases.  Updates  would  be  performed  on  the  existing  systems  and  either  pre-aggregated 
or  relational  data  would  be  created  and  provided  to  "information  centers"  to  be  used 
for  processing  information  requests." 

From  DSAC  -  "Security  is  a  principle  element  that  needs  to  be  addressed.  DSAC  is 
concerned  that  this  vision  seems  to  leave  security  control  process  outside  of  the  basic 
platforn*  evolution.  In  our  view,  the  security  issues  of  process  integrity,  data 
integrity,  effective  and  efficient  user  identification/authentication  and  management 
must  be  recognized  as  an  integral  part  of  the  IRM  process." 

From  DASC  -  "Expand  to  include  ICs  in  DLA.  IC  organization  provides  end-user 
support. "  I 
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6.  EXECUTIVE  SUMMARY 


This  paper  prescribes  a  re-engineered  IRM  Data,  Process,  network,  technology  and 
organizational  environment  targeted  for  the  mid-1990s  and  beyond  (after  the  consolidation 
environments  are  normalized).  Since  there  is  no  certain  way  of  knowing  the  impact  of 
programs  such  as  the  CIM,  this  paper  is  designed  to  be  as  generic  and  flexible  as  possible. 

It  is  also  recognized  that  any  new  efforts  without  a  CIM  label  are  unlikely  to  be  funded  in 
the  next  few  years.  Because  of  that  practical  reality,  DLA  can  only  continue  to  prepare  for 
rather  than  execute  specific  aspects  of  this  paper’s  prescription  which  require  investment 
funding. 

The  concepts,  policies  and  facilities  prescribed  in  this  paper  are  appropriate  whatever  the 
consequences  of  the  programs  in  progress  today.  They  may  be  applied  to  DLA  or  to  DoD; 
corporate  data  may  be  scoped  by  DLA  mission  area,  by  DLA  in  total,  by  a  DoD  mission 
area  or  by  DoD  in  total.  The  concepts  remain  appropriate  regardless  of  scope.  There  is  no 
attempt  to  design  DLA’s  future  systems  but  to  prescribe  environment  and  migration 
necessities  which  will  assure  a  cost/effective  operating  environment  for  IRM,  These 
concepts  include  the  sharing  of  data  across  the  corporate  scope,  the  treatment  of  IRM  as  a 
mission  essential  management  entity  with  its  own  I/S  needs,  the  development  of  common 
applications  architectures  assembled  from  foundation  application  and  technology  components 
which  can  be  considered  the  Lego  blocks  from  which  all  systems  are  built,  the  vision  of 
network  computing  where  the  network  is  the  computing  environment  not  just  the 
communications  link,  the  policy  of  "State  of  the  Contract  Design"  to  assure  integration  and 
to  eliminate  waiting  for  acquisitions  at  critical  times,  the  adoption  of  standards  assuring  an 
open  systems  environment  with  flexibility,  the  use  of  automated  systems  engineering  enablers 
to  cope  with  the  enormous  complexities  of  enterprise-wide  analysis,  the  infusion  of  up-to-date 
cost  effective  technologies,  and  an  organizational  environment  that  is  flexible  but  firm  in  its 
commitment  to  providing  cost  effective  support  to  its  customers. 

Although  this  paper  prescribes  an  environment  that  is  expected  to  be  cost  effective,  DLA  will 
continue  to  be  constrained  by  inefficient  acquisition  methodologies.  While  DLA  is  unable  to 
fundamentally  change  the  acquisition  rules,  it  is  hoped  that  its  "Design  to  the  State  of  the 
Contract"  policy  makes  them  viable. 
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Full  achievement  of  the  environment  prescribed  by  this  paper  requires  fundamental  paradigm 
shifts  in  information  systems  design,  technology  usage  and  personnel  organization.  Because 
of  the  difficulties  inherent  in  paradigm  changes,  the  paper  pays  particular  attention  to 
potential  migration  strategies.  A  concept  for  cross  model  resolution  which  allows  continuous 
re-engineering  of  applications  while  data  is  being  asynchronously  migrated  is  being 
researched.  The  paper  describes  combinations  of  scenarios  for  implementation  using  cross 
model  resolution  as  the  primary  "Change  in  Place"  implementation  mode  and  a  fresh  start 
approach  referred  to  as  "ANDES"  (A  New  DLA  Environment  Seed).  DLA  must  decide 
which  alternative  to  adopt  and  dedicate  resources  to  it.  Considerable  long  term  gains  are 
achievable  if  DLA  does  the  up-front  investment  in  re-engineering.  The  longer  DLA 
continues  to  add-on  and  modify  existing  systems  without  fundamental  re-engineering  the 
more  inherently  inefficient  they  become. 

Because  of  the  current  !PC  consolidation  scenarios  that  are  already  under  way,  it  may  appear 
that  DLA  may  have  five  or  more  years  before  it  should  start  filling  the  prescriptions  of  this 
paper.  While  this  paper  may  describe  an  environment  that  DLA  may  want  to  achieve,  it 
does  not  pretend  to  be  fully  detailed.  Much  work  needs  to  begin  now,  in  parallel  with  the 
consolidation  efforts,  to  complete  the  picture  and  to  assure  that  DLA  is  prepared  to  absorb 
the  significant  paradigm  shifts  that  are  inevitable.  Regardless  of  what  the  additional  detailing 
of  this  prescription  may  reveal,  it  is  paramount  that  DLA  not  delay  development  of 
Corporate  data  and  process  models  utilizing  good  information  engineering  methodologies. 
Without  these  models  DLA  would  have  no  defined  target  to  strive  towards,'”! .  These 
models  are  necessary  for  change  in  any  conceivable  scenario  other  than  continued  cluttering 
of  the  present  systems,  which  at  one  time  were  functional/technical  marvels,  but  are  now 
unable  to  extract  the  maximum  advantage  and  efficiencies  achievable  through  current 
technology  and  concepts  of  information  systems. 


^^Have  you  ever  put  a  jigsaw  puzzle  together  without  the  picture?... Lou  Tine 
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This  chart  represents  a  potential 
DLA  IRM  organization  structure 
for  the  prescibed  re-engineered 
envi ronment. 


The  actual  number  of  I PCs  is  not 
significant  to  the  concepts  presented 
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idation  projects  will  set  the  number. 


Eventually  the  I PCs  may  take  on  a 
"Utility"  appearance  without  a  specific 
business  area  assignment. 


**It  is  likely  that  the  STINFO 
applications  will  be  operated  by  the 
Military  District  of  Washington’s  IPC 
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-  DATA  ENTITIES  FOR  INFORMATION  RESOURCE  MANAGEMENT 
(WORKSHEET) 

The  ROUGH  STRAWMAN  DRAFT  of  entities  listed  here 
includes  many  potential  sub-entities  and 
attributes;  this  needs  to  be  cleaned  up  to 
differentiate  between  entities  and  attributes  and 
verified  by  DLA's  IRM  organizations.  This  list  is 
only  to  be  utilized  as  a  starting  point  for 
discussion  and  determination  of  the  official  IRM 
entities.  When  resolved  the  list  becomes  the 
Business  Scope  of  Data  entry  into  the  first  layer 
of  the  Zachman  Framework  for  I/S  Architecture  (See 
Enclosure  5) . 
r  DLA  BUSINESS  REQUIREMENTS 

r  BUSINESS  CONSTRAINT 

■  BUSINESS  CRITICAL  SUCCESS  FACTORS 

-  BUSINESS  ENTITIES 

-  BUSINESS  GOALS 

-  BUSINESS  OBJECTIVES 

(-  FUNCTIONAL  OBJECTIVE 
r  SYSTEM 

-  PROCESS 

—  BUSINESS  SUBJECT  AREA 

-  ACTIVITY 

—  APPLICATIONS 
*-  TASK 
I/S  OBJECTIVE 
r  DATA  ENTITY 

-  DATA  RELATIONSHIP 

-  DATA  SUBJECT  AREA 
*-  ATTRIBUTE 

-  BUSINESS  MISSION 

-  BUSINESS  OPERATIONAL  OBJECTIVE 

■  BUSINESS  PROCESSES 

-  BUSINESS  STRATEGIC  OBJECTIVE 

E  TACTIC 
PLAN 
PROGRAM 

-  BUSINESS  TACTICAL  OBJECTIVE 
*-  BUSINESS  UNIT  GROUPS 
-  DLA  BUSINESS  TRANSACTIONS 
r  CATALOG  A  NEV  ITEM 
-  ESTABLISH  A  NEV  CONTRACT 
-  EXCESS  MATERIAL  OFFER 
-  MATERIAL  RECEIPT 
-  MATERIAL  REQUISITION 
-  NEV  ITEM  ASSIGNMENT 
-  PAYMENT 

-  PROVISIONING  SCREENING 
*-  SHIPPING  ORDER 
-  IRM  ADMINISTRATIVE  ACTIVITY 
r  ASSIGNMENTS 

-  EMPLOYEE  AVARD/REC06NITI0N 

-  MEETINGS  -  (BRIEF.  CLASS.  CONFERENCE,  SYMPOSIIM.  ETC.) 
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r  TYPE  MEETING 
r  Briefing 

■  Class 
Comittee 

■  Conference 
Symposium 

■  Agenda 

Briefing  Charts 
*-  MISCELLANEOUS  EVENTS 
M  CORRESPONDENCE 
•  ACQUISITION  SOLICITATION 
r  IFB 
*-  RFP 

-  INCIDENT  REPORT 

-  lOM 

-  MFR 

■  ROUTING  LIST 
yORK  OROER/UORK  REQUEST 

E  SYSTEM  CHANGE  REQUEST 
TASKING 

TECHNOLOGY  WORK  REQUEST 
i  EXTERNAL  INTERFACES 
-  AUDITORS 

E  DAI SRC 
MAISRC 
GSA 

■  CLIENTS 
’  CONTRACTORS 

-  CORPORATE  BUSINESS  FUNCTIONAL  PROPONENTS 

[CORPORATE  MANAGEMENT 
-  OLA  DIRECTOR 
PRINCIPLE  STAFF  ELEMENTS 
~  STAKE  HOLDERS 
•  END  USERS 
■  SUPERIORS 
■  SUPPLIERS 

■  TECHNOLOGY  USER  GROUP 
■  VENDOR 
PLANS 

■  ACQUISITION 
■  ACTION 

-  AIS  MASTER  PROGRAM  PLAN 

(Mentioned  in  IRM  Plan  page  II-l) 

-  DEFICIENCIES 
r  FUNCTIONAL 
*■  CORPORATE  SUPPORT 
^  INITIATIVES 

~  INITIATIVE  PROGRAM  MANAGER 

BUDGET 

E  ANNUAL  BUDGET 
BUDGET  LINE 
POM 
CAPACITY 
IRM 
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r  NEAR-TERM 
^  LONG-TERM 
*-  PROGRAM 

—  PROGRAM  MANAGER 
-  IRM  POLICY  AND  REGULATION 
r  EXTERNAL 

r  CONSTRAINT 

■  GUIDELINE 

r  DEFENSE  MANAGEMENT  REPORT  DECISIONS  (DMRDs) 

-  OLA  STRATEGIC  PLAN 

-  000  CORPORATE  INFORMATION  MANAGEMENT  (CIM) 
*-  DQD/DLA  BUDGET  GUIDANCE 

-  LEGISLATION 

-  REGULATION 
STANDARD 

INTERNAL 

r  ASSUMPTION 

■  CONSTRAINT 

-  CONVENTION 

■  DIRECTIVES 

-  GUIDES 

—  TECHNOLOGY  INTEGRATION  GUIDE 

-  HANDBOOKS 

-  POLICY  STATEMENT 

-  PROCEDURES 

-  REGULATIONS 
STANDARD 

■  IRM  PRODUCTS  AND  SERVICES 

r  OPERATIONS  PERFORMANCE  RATING 

(See  IBM  mgng  the  data  processing  org  page  66) 

E  WORKLOAD 

UTILIZATION  OF  RESOURCES 
COST 

r  SALARIES  AND  RELATED  EXPENSES 
-  OCCUPANCY  AND  RELATED  EXPENSES 
-  EQUIPMENT  AND  RELATED  EXPENSES 
■  COMMUNICATIONS  AND  RELATED  EXPENSES 
■  OPERATING  SUPPLIES 
■  OTHER  OPERATING  EXPENSES 
^  ALLOCATED  EXPENSES 

-  REPORT 
-  OISPR 

-  USER  SERVICE  LEVEL  AGREEMENT 
USER  SERVICE  LEVEL  RATING 
r  I/S  RATING 
*-  USER  RATING 
■  IRM  PROJECTS 

r  IMPLEMENTATION 

r  NEW  APPLICATIONS 
■-  APPLICATION  CHANGES 
*  RESEARCH  AND  FEASIBILITY  STUDIES 
r  TECHNICAL 
-  FUNCTIONAL 
■  ORGANIZATIONAL 
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METHODS  AND  PROCEDURES 

■  STATUS  REPORT 

•  PR06RAH 

—  PROJECTS 
r  EVENT 
^  MILESTONE 

■  SCHEDULE 
TARGET  DATE 

IRM  REQUIREMENTS 

-  I/S  BUSINESS  ENTITIES 

-  I/S  CONSTRAINT 

■  I/S  CRITICAL  SUCCESS  FACTORS 

-  I/S  GOALS 

-  I/S  MISSION 

-  I/S  OPERATIONAL  OBJECTIVE 

•  I/S  PROCESSES 

r  CAPACITY  MANAGEMENT 
r  CAPACITY  PLANNING 
^  PERFORMANCE  ANALYSIS 

-  CONFIGURATION  MANAGEMENT 

-  DEVELOPMENT 

-  END-USER  SUPPORT 

-  FINANCIAL  MANAGEMENT 

r  BUDGETING 

^  COST  BENEFIT  ANALYSIS 

■  OPERATION 

■  PERSONNEL  MANAGEMENT 

•  POLICY  DEVELOPMENT 

■  PROJECT  MANAGEMENT 

*  REQUIREMENTS  ANALYSIS 

■  RESEARCH 

-  REVIEW  AND  EVALUATION 

STANDARDS  AND  PROCEDURES  DEVELOPMENT 

•  I/S  STRATEGIC  OBJECTIVE 

-  I/S  TACTICAL  OBJECTIVE 
*"  I/S  UNIT  GROUPS 

IRM  RESOURCES 

■  APPLICATIONS  (STANDARD  AND  UNIQUE) 

r  PROGRAM 
*-  MODULE 

-  COMMUNICATIONS  NETUORK 

r  WIDE-AREA 
r  LOCAL-AREA 
WORK-AREA 

■  CONTRACT 

•  DATA 

r  DATA  BASE 
FILE 

•  FACILITIES/ENVIRONMENT 

-  SITE 

r  AIR  CONDITIONING 

■  ELECTRICAL  POUER 

■  FURNISHINGS 

-  PHYSICAL  SPACE 
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Wed , 


h  REFERENCE  LIBRARY 
SUPPLIES 
HARDWARE/SOFTVME 

■  COMPUTER 

■  CONFIGURATION 

■  OATA  STORAGE 

-  ENVIRONMENTAL  REQUIREMENT 

E  SPACE 
POUER 
AIR 

■  MAINTENANCE  REQUIREMENT 
-  NETWORK 

TECHNICAL  SOFTWARE 
-  CASE  TOOL 
■  DBMS 

•  NETWORK  MANAGER 
-  OPERATING  SYSTEM 
•  PROGRAMING  LANGUAGE 
*■  TRANSACTION  MANAGER 


MONEY 

ORGANIZATION 

-  FUNCTION 

-  INDIVIOUAL  TRAINING  PLAN 

■  KNOWLEDGE.  SKILL.  ABILITY  REQUIREMENTS 

-  MISSION 

■  PERFORMANCE  EVALUATION 
PERFORMANCE  STANDARD 

r  PERSONNEL 

r  PERSONNEL  TYPE 

1  POLICY 

2  REQUIREMENT  ANALYSIS 

3  DESIGN  SPECIFICATION 

4  IMPLEMENTATION 
“  APPLICATION  DEVELOPMENT 

ANALYSIS 
DESIGN 
PROGRAMMING 
TEST 

INSTALLATION 
MAINTENANCE 

POST  INSTALLATION  EVALUATION 

5  OPERATION 

E  SCHEDULING  AND  CONTROL 
EQUIPMENT  OPERATIONS 
PRODUCTION  SUPPORT 
6  MANAGEMENT 

PLANS  AND  CONTROLS 
PERSONNEL  AND  TRAINING 
FINANCIAL  MANAGEMENT 
ADMINISTRATIVE  SERVICES 
USER  LIAISON 
SECURITY 

TECHNICAL  SUPPORT/INTEGRATION 
[-  STANDARDS 
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■  TECHNICAL  ASSISTANCE 

■  SYSTEM  PROGRAMMING 

■  DATA  BASE  MANAGEMENT 

■  COMMUNICATIONS  NETWORK  MANAGEMENT 
SYSTEM  EVALUATION  AND  CONFIGURATION 

■  RESEARCH  AND  DEVELOPMENT 
^  TECHNOLOGY  INTEGRATION 

■  LOCATION 
-  NAME 

^  PHONE  NUMBER 
-  POSITION  DESCRIPTION 

EANAtyST 
PROGRAMMER 
SUPERVISOR 
■  RESPONSIBILITY 
^  WORK  SHIFT 
■  SUPPLIES 
^  TRAINING  PROGRAMS 
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DEVLP  REAL-WORLD  DATA  MODEL 
ATTAIN  CASE  CAPABILITY 
DEVLP  TARGET  DATA  MODEL 
ATTAIN  XMR  CAPABILITY 
DEVLP  COMMON  BUS  PROC  MODULES 
MAINTAIN  DATA  MODEL(s) 

COMMIT  TO  CIP  STRTGY  &  SCOPE 
EXECUTE  DATA  TRANSITIONS 
DEVLP  NEW  APPLICATIONS 
DISCRD  OLD  APPLICATIONS 


D  Done  •==  Task  -  Slack  time  (== — ).  or 

C  Critical  +++  Started  task  Resource  delay  (— »=) 

R  Resource  conflict  M  Milestone  >  Conflict 

p  Partial  dependency 

Scale:  Each  character  equals  1  month 


TIME  LINE  Gantt  Chart  Report 


Strip  1 


CHANGE  IN-PLACE  IMPLEMENTATION  STRATEGY 


1.  CHANGE  IN-PLACE  IMPLEMENTATION  STRATEGY 

1.1.  REQUIREMENTS  COMMON  TO  ALL  SCENARIOS 

1.1.1.  ATTAIN  COMPUTER  ASSISTED  SYSTEMS  ENGINEERING  CAPABILITY 

1.1. 1.1.  The  CASE  environment  must  provide  for  information  engineering  covering  the  entire 
spectrum  from  Business  Area  Analysis  through  non-technol ogy  specific  code  generation . 

1.1.2.  DEVELOP  COMMON  BUSINESS  PROCESS  FOUNDA  TION  HODUL  ES 

1.1. 2.1.  Comon  low-level  business  process  modules  that  may  be  asserbled  (with  the  addition  of 
appl ication  unique  outer  shell  logic)  into  applications  should  be  identified  and 
developed. 

1.2.  THE  CHANGE  IN-PLACE  ALTERNATIVE  SCENARIO  CHANGES  THE  IRM  ENVIRONMENT  THROUGH  A  GRAOUAL 
RE-ENGINEERING  OF  DATA  ANO  PROCESSES  UNTIL  THE  ENTIRE  TRANSITION  IS  COMPLETED.  SINCE  OLD  AND 
NEW  SYSTEMS  WOULD  CO-EXIST  AND  INTER-OPERATE  THIS  ALTERNATIVE  WOULD  MAKE  EXTENSIVE  USE  OF  CROSS 
MODEL  RESOLUTION. 

1.2.1.  ATTAIN  CROSS  MODEL  RESOLUTION  CAPABILITY. 

1.2. 1.1.  Acquire  or  develop  the  capability  to  viably  perform  cross  model  resolution . 

1.2.2.  COMMIT  TO  CHANGE  IN-PLACE  STRATEGY  AND  DATA  SCOPE. 

1.2. 2.1.  Determine  Corporate  Data  Scope  Alternati ves . 

1.2. 2. 1.1.  Consider: 

1.2. 2. 1.1.1.  DLA-yide. 

1.2. 2. 1.1. 1.1.  Conbines  the  data  needs  of  the  DLA  into  one  logical  data  moonl . 

1.2. 2. 1.1. 2.  Major  DLA  Thrust  A rea  Hide . 

1.2. 2. 1.1. 2.1.  Creates  logical  data  models  for  each  major  thrust  area  defined  in  the 
CFR  and/or  Strategic  Dbjecti ves .  Implies  redundancies  across  thrust 
areas  . 

1.2. 2. 1.1. 3.  Current  Appl ication  Wide. 

1.2. 2. 1.1. 3.1.  Logical  data  models  would  be  developed  for  each  of  DLA' s  current 
application  areas  with  no  change  in  scope.  Implies  redundancies 
across  each  application  area;  e.g.  SAMMS ,  OVASP,  DIDS,  MOCAS ,  etc. 

1.2. 2. 1.1. 4.  DoD-Uide. 

1.2.2. 1. 1.4.1.  Conbines  the  data  needs  of  the  DoD  into  one  logical  data  model .  This 
decision  would  put  the  execution  beyond  the  scope  of  DLA’s  authority. 

1.2. 2. 2.  Gain  Agency-Vide  camitment  to  the  Change  In-Place  strategy  and  data  scope. 

1.2. 2. 2.1.  Train  appropriate  personnel  on  concepts. 

1.2.3.  DEVELOP  TARGET  DATA  MODEL  . 

1.2. 3.1.  Develop  detailed  target  data  models  using  appropriate  information  engineering 
methodol ogi es . 

1.2. 3. 2.  Attain  Agency  comitment  to  target  data  models. 

1.2.4.  DEVELOP  REAL  -NORLO  DA TA  MODEL  . 

1.2. 4.1.  Develop  data  models  of  existing  data  environments. 

1.2.5.  DEVELOP  NEW  APPL  ICA TIONS  . 

1.2. 5.1.  Develop  new  applications  using  appropriate  information  engineering  methodologies. 

1.2. 5. 2.  The  new  appl ications  would  utilize  the  target  data  models. 

1.2. 5. 2.1.  The  cross  model  resolver  would  resolve  differences  between  real-world  data 
models  and  target  models  until  they  become  identical  through  data  transition 
efforts . 

1.2.6.  EXECUTE  DATA  TRANSITIONS. 

1.2. 6.1.  Determine  sequence  of  data  transitions . 

1.2. 6. 1.1.  Consider: 

1.2. 6. 1.1.1.  Performance  needs . 

1.2. 6. 1.1. 1.1.  Uhere  the  data  in  the  current  systems  is  very  inefficient  to  access  in 
the  target  model  view. 

1.2. 6. 1.1. 2.  Removal  of  old  data  bases. 

1.2. 6. 1.1. 2.1.  yhen  possible  move  data  out  of  entire  old  data  bases  so  that  they  may 
be  removed  as  early  as  possible. 
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1.2. 6. 2.  Attain  Agency  conmitnient  to  data  transition  sequence. 

1.2. 6. 3.  Execute  data  transitions. 

1.2.7.  DISCARD  OL  D  APPL ICA  TIONS . 

1.2. 7.1.  Old  applications  may  be  discarded  as  soon  as  the  functionality  in  them  is  replaced  by 
new  functional ity  in  the  newly  engineered  applications. 

1.2.8.  MAINTAIN  DA TA  HQDEL(s)  . 

1.2. 8.1.  As  each  data  transition  from  real-world  data  bases/files  to  target  data  bases  occurs 
the  real-world  and  target  data  models  must  be  updated. 

1.2. 8. 2.  yhen  the  real-world  and  target  data  models  are  identical  the  data  transition  is 
complete. 
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Jan 

Status  2 

ATTAIN  CASE  CAPABILITY 
DEVLP  COMMON  BUS  PROC  MODULES 
COMMIT  TO  ANDES  STRTGY  &  SCOPE  C 
DETERMINE  ANDES  MISSION  SCOPE 
DEVELOP  ANDES  ENVIRONMENT 
STAFF  ANDES 


DEVELOP  SYSTEMS  ARCHITECTURE  C 

DEVELOP  SYSTEMS  C 

IMPLEMENT  SYSTEMS  C 

ASSUME  RESPONSIBLITY  W/I  SCOPE 
EXPAND  ANDES  MISSION  8.  SCOPE  C 

TO  NEXT  SCOPE  CYCLE  TILL  DONE  C 
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D  Done  ===  Task  -  Slack  time  (=» — ).  or 

C  Critical  +++  Started  task  Resource  delay  { — *=) 

R  Resource  conflict  M  Milestone  >  Conflict 

p  Partial  dependency 

Scale;  Each  character  equals  1  month 
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1.  A  NEW  DLA  ENVIRONMENT  SEED  (ANDES)  IMPLEMENTATION  STRATEGY 

1.1.  REQUIREMENTS  COMMON  TO  ALL  SCENARIOS 

1.1.1.  ATTAIN  COMPUTER  ASSISTED  SYSTEMS  ENGINEERING  CAPABILITY 

1.1. 1.1.  The  CASE  environment  must  provide  for  information  engineering  covering  the  entire 
spectrum  from  Business  Area  Analysis  through  non -technology  specific  code  generation. 

1.1.2.  DEVELOP  COMMON  BUSINESS  PROCESS  FOUNDATION  MODULES 

1.1. 2.1.  Comon  lou-level  business  process  modules  that  may  be  assentled  (with  the  addition  of 
appl ication  unique  outer  shell  logic)  into  appl i cati ons  should  be  identified  and 
developed. 

1.2.  THE  ANDES  ALTERNATIVE  SCENARIO  CREATES  A  NEW  ENVIRONMENT  BEYOND  THE  EXISTING  DLA  ENVIRONMENT. 
DLA  MISSION  FUNCTIONS  WOULD  GRADUALLY  BE  TRANSFERRED  TO  THE  NEW  ENVIRONMENT  AS  IT  GROWS  IN 
CAPABILITY  TO  ACCEPT  THEM.  THIS  ALTERNATIVE  DOES  NOT  REQUIRE  INTEGRATION  OF  THE  OLD  AND  NEW 
ENVIRONMENTS  AND  DOES  NOT  REQUIRE  CONVERSION  OF  LEGACY  APPLICATIONS. 

1.2.1.  COMMIT  TO  ANDES  STRATEGY  AND  DATA  SCOPE. 

1.2. 1.1.  Determine  Corporate  Data  Scope  Alternati ves . 

1.2. 1.1.1.  Consider: 

1.2. 1.1. 1.1.  DLA-Vide. 

1.2. 1.1. 1.1.1.  Conbines  the  data  needs  of  the  DLA  into  one  logical  data  model . 

1.2. 1.1. 1.2.  Major  OLA  Thrust  Area  Wide . 

1.2. 1.1. 1.2.1.  Creates  logical  data  models  for  each  major  thrust  area  defined  in  the 
CFR  and/or  Strategic  Objectives.  Implies  redundancies  across  thrust 
areas . 

1.2. 1.1. 1.3.  DoD-yide. 

1.2. 1.1. 1.3.1.  Conbines  the  data  needs  of  the  DoD  into  one  logical  data  model  .  This 
decision  would  put  the  execution  beyond  the  scope  of  DLA  's  authority. 

1.2. 1.2.  Gain  Agency-Uide  commitment  to  the  ANDES  strategy  and  data  scope. 

1.2. 1.2.1.  Train  appropriate  personnel  on  concepts. 

1.2.2.  DETERMINE  INITIAL  ANDES  MISSION  SCOPE 

1.2. 2.1.  Establish  Small  Core  ANDES  Planning  Team 

1.2. 2. 2.  Decide  on  Implementation  Strategy 
Centralized 

Decentralized 
Distribi  i 

Regiona  'ed  (Assumed  in  rest  of  paper) 

.  Functionally  (Assumed) 

.  Geographical ly 

1.2. 2. 3.  Determine  Federal  Stock  Classes  for  ANDES  Management 

1.2. 2. 3.1.  Select  Class(s)  that  fit  in  Current  Region 

1.2. 2. 3. 1.1.  Preferably  a  straight-forward  Cl ass(s)  with  a  total  of  a  few  hundred  items 
at  the  mast  . 

1.2.3.  STAFF  ANDES  (This  step  repeated  for  each  mission  scope  increase) 

1.2. 3.1.  Design  Organization  Structure 

1.2.3. 1.1.  Assign  Specific  Responsibilities 

1.2.3. 1.2.  Assign  Specific  Authorities . 

1.2. 3. 2.  Determine  Staffing  Types  and  Levels 

1.2. 3. 2.1.  Information  Systems  Personnel 

1.2. 3. 2. 2.  Functional  Personnel 

1.2. 3. 2. 3.  Contractor  Personnel 

1.2. 3. 3.  Determine  Location  of  Staff 

1.2. 3. 3.1.  Determine  which  staff  will  be  located  at  ANDES  site  versus  at  current  sites  with 
ANDES  access. 

1.2.4.  DEVELOP  ANDES  ENVIRONMENT 

1.2. 4.1.  Install  Information  Systems  Envi ronment 

1 . 2 . 4 . 1 . 1 .  Determine  ANDES  I/S  S i zi ng 
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1 . 2 . 4 . 1 . 2 .  Acqui  re  Harduare/Softuare 

1.2. 4. 2.  Install  Functional  Environment 

1.2. 4. 2.1.  Make  new  functional  operational  decisions  such  as  Just-i n-Time  Inventory  versus 
large  inventories  etc.  Determine  facilities  necessary.  Share  facilities  with 
existing  DLA  only  as  appropriate  such  as:  Bases,  Buildings,  Furniture  and 
supplies,  etc. 

1.2.5.  DEVELOP  SrSIEHS  ARCHITECTURE 

1 . 2 . 5 . 1 .  Deve! op  Data  A rchi lecture 

1 . 2 . 5 . 2 .  Develop  AppI i cat i ons  A rchi lecture 

1.2.6.  DEVELOP  SYSTEMS 

1.2. 6.1.  Develop  Subject  Data  Bases  at  Decided  Scope 

1 . 2 . 6 . 2 .  Develop  AppI i cat i ons  necessary  for  ANDES  Scope 

1.2. 6. 2.1.  CASE  tools  with  4th/5th  generation  technologies  will  be  utilized.  Development 
will  occur  via  User/Developer  teams.  Performance  requirements  will  be  specified 
prior  to  development.  If  performance  objectives  are  not  met  the  application 
will  be  rewritten  in  a  procedural  language  else  it  will  be  left  in  the  4GL  . 
Either  standard  procedural  or  easily  rewritten  4GLs  will  be  considered  as 
satisfying  program  portabi I i ty  objecti  ves . 

1.2.7.  IMPLEMENT  SYSTEMS 

1.2. 7.1.  Train  Users 

1.2. 7. 2.  Transfer  Production  Data  Uithin  Scope  From  DLA  Files 

1.2. 7. 3.  Turn  New  System(s)  on 

1.2.8.  ASSUME  RESPONSIBIL ITY  UI THIN  SCOPE 

1.2. 8.1.  Transfer  Management  Responsibility  from  DLA 

1.2. 8. 2.  Determine  Uhether  All  Responsibilities  Achieved 

If  all  regions  are  completed  the  Transition  is  Complete. 

1.2.9.  EXPAND  ANDES  MISSION  SCOPE  ->Loop  to->  STAFF  ANDES 

1.2. 9.1.  Select  Next  Region  If  Current  Complete 

1.2. 9. .2.  Determine  Additional  Mission  Scope  for  ANDES  Management 

1 . 2 . 9 . 2 . 1 .  FSCs  for  ANDES  Managment 

1.2. 9. 2. 2.  Contract  Types  for  ANDES  Management 
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INFORMAnON  SYSTEMS 
•  ARCHTTECTURE  COMPONENTS 

_ (LEGO  BLOCKS) 
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INFORMATION  INTERFACE  REQUIREMENTS  BETWEEN 
IRM  ORGANIZATIONAL  ELEMENTS,  PSEs  AND  END-USERS 


(Depicts  only  critical  information  flows  -  Not  end  products) 
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CRITICAL  INFORMATION  FLOWS 


The  numbering  scheme  used  here  generally  reflects,  although  imprecisely,  the  sequence 
in  which  the  various  information  interfaces  will  occur. 


1.00  FUNCTIONAL  REQUIREMENT 

This  is  the  initial  passing  of  the  business  functional  requirement  from  the  PSE  to  IRM 
Hqs.  As  in  all  cases  to  follow,  this  information  will  be  passed  by  way  of  the 
Corporate  Enterprise  Model  Repository  (referred  to  simply  as  the  repository  from 
here  on).  The  metadata  detail  would  correspond  to  the  Business  Scope  level  of 
Zachman’s  framework. 

1.10  BENEFIT  ESTIMATE 

This  is  the  PSE’s  estimate  of  benefits  to  DLA  if  the  functional  requirement  is 
automated.  This  gives  the  IRM  Hqs  some  idea  on  what  automation  solution 
alternatives  may  be  cost/effective. 

1.53  AUTOMATION  REQUIREMENT 

This  is  the  PSE’s  business  requirement  after  having  been  information  engineered  to 
the  next  level  of  detail.  The  metadata  detail  would  correspond  to  the  Business  Model 
level  of  21achman’s  framework. 

1.57  BENEFIT  MARGIN  GOAL 

This  is  the  specific  margin  of  benefits  over  cost  to  be  achieved  by  the  automation  of 
this  functional  requirement.  This  margin  will  be  passed  along  with  the  automation 
requirement  to  the  IRM  Design  Element  as  a  specific  limit  on  the  costs  of  the 
automated  system  to  be  developed.  The  margin  would  normally  be  a  percentage 
standard  (such  as  10%)  but  would  be  individually  set  by  negotiation  between  the  Hqs 
IRM  and  the  PSE. 

1.60  SYSTEMS  ARCHITECTURE/INTEGRATION  GUIDANCE 

This  is  the  guidance  provided  by  the  IRM  Hqs  to  the  Design  Element  on  standards  to 
follow,  information  technology  components  that  are  available  to  the  Agency,  etc. 

This  information  would  be  passed  as  necessary  in  the  form  of  official  IRM  Plans, 
Technology  Plans,  Technology  Integration  Guide,  etc. 
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2.50  INITIAL  AUTOMATION  COST  ESTIMATE 

This  is  the  first  blush  gross  cost  estimate  developed  by  the  IRM  Hqs  so  that  the  PSE 
may  be  provide  the  opportunity  to  adjust  the  function^  requirement  or  let  it  stand. 

2.80  PRELIMINARY  AUTOMATION  DECISION 

This  is  the  decision  to  go  ahead  with  a  more  detailed  cost  estimate  after  receiving  the 
initial  cost  estimate. 

3.00  DETAILED  AUTOMATION  COST  ESTIMATE 

This  is  the  detailed  cost  estimate  developed  by  the  IRM  Design  Element.  The  detail 
of  this  estimate  must  be  adequate  enough  for  the  PSE  to  make  a  determination  as  to 
whether  or  not  to  automate  (at  least  with  that  design  element).  The  PSE  should  be 
able  to  evaluate  expected  charge-back  costs  to  benefits  expected. 

3.30  AUTOMATION  ORDER 

This  is  the  order  to  begin  design  and  implementation  of  the  automated  system  after 
having  assessed  that  the  system  will  be  cost/effective. 

3.50  DETAILED  END  USER  REQUIREMENTS 

These  are  the  detailed  end-user  requirements  that  are  determined  through  integrated 
designer/end-user  development  teams.  These  requirements  would  generally  take  the 
shape  of  screen  formats,  help  screen  analysis,  expert  system  advisory  add-ons,  etc. 
They  establish,  within  the  context  of  the  original  requirement,  the  specific  user 
interfaces  that  are  acceptable. 

3.53  I/S  RESOURCE  RE(JUIREMENTS 

These  are  the  specific  information  technology  (IT)  and  I/S  personnel  resource 
requirements  necessary  to  implement  the  automated  system. 

3.57  USER  INTERFACE  PROTOTYPE 

This  is  a  prototype  of  the  user  interface  to  the  automated  system  that  is  developed 
through  integrated  designer/end-user  development  teams.  This  interface  would 
generally  take  the  shape  of  screen  formats,  help  screen  analysis,  expert  system 
advisory  add-ons,  etc. 
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3.60  BUDGET  LIMITS 

These  are  specific  cost  limits  for  the  operation  of  an  automated  system.  The  costs 
would  be  associated  with  units  of  work,  e.g.  cost  per  requisition,  cost  per  contract 
modification,  cost  per  paycheck,  etc.  so  that  the  IRM  Oj^rating  Element  can  budget 
his  overall  expenses.  These  budget  limitations  would  be  utilized  as  one  of  the  prime 
factors  (along  with  user  satisfaction  level  reports)  in  rating  the  effectiveness  level  of 
an  IPC. 

3.70  IMPLEMENTATION  DECISION 

This  is  the  order  to  go  ahead  with  the  development  of  the  automated  system.  The 
PSE  would  make  this  decision  based  upon  all  cost/benefit  assessments  received. 

3.75  I/S  RESOURCE  APPROVAL 

This  is  the  approval  for  expenditures  of  resources  for  development  of  the  automated 
system. 

3.82  END  USER  GUIDE 

This  is  the  manuals,  on-line  screens,  computer  assisted  training  devices,  etc.  that  are 
provided  to  the  end-user  of  the  automated  system  for  help  in  using  the  system. 

3.84  I/S  HELP 

This  is  any  help  necessary  in  operating/using  the  automated  system. 

3.88  I/S  OPERATIONS  GUIDE 

This  is  the  manuals,  on-line  screens,  computer  assisted  training  devices,  data  base 
backup  facilities,  diagnostics,  etc.  that  are  provided  to  the  IRM  Operating  Element  for 
use  in  operating  the  automated  system.  The  IRM  Operating  Element  responsibilities 
may  be  delegated  to  the  end-user  for  IT  distributed  to  the  user’s  environment. 

3.90  OPERATIONS  REPORTS 

These  are  operations  reports  that  describe  the  effectiveness  levels  of  the  operational 
environment,  e.g.  transactions  processed,  equipment  and  software  failures,  hours  on¬ 
line,  abnormalities,  user  complaints,  resource  utilization  levels,  etc. 


3.95  I/S  RESOURCE  APPROVAL 

This  is  the  approval  for  expenditures  of  resources  for  the  operation  of  the  automated 
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system. 

4.00  OPERATIONAL  GUIDANCE 

This  is  the  guidance  provided  by  the  functional  proponent  (PSE)  to  the  end-users  of 
the  automated  system.  This  guidance  would  consist  of  business  policies  on  the  use  of 
the  system,  eg.  under  what  circumstances  you  would  not  authorize  a  purchase  from  a 
supplier,  when  to  re-order  material,  when  to  refuse  a  loan,  etc.  Of  course;  most  of 
these  business  policies  will  be  built  into  the  system  generally  by  integrated  expert 
systems. 

4.50  I/S  SERVICES  EVALUATION 

This  is  the  scorecard  of  overall  satisfaction  of  the  information  system  in  terms  of 
performance  and  cost.  Based  upon  this  appraisal  the  IRM  Hqs  may  make  system 
repairs  and  service  improvements  or  possibility  alter  the  charge-back  criteria. 
Hopefully  all  that  would  need  to  be  done  would  to  be  to  issue  awards  to  the 
organizations/personnel  responsible  for  a  well  designed/well  operated  system. 

5.00  I/S  RESOURCE  REQUIREMENTS 

These  are  the  specific  information  technology  (IT)  and  I/S  personnel  resource 
requirements  necessary  to  operate  the  automated  system. 

5.10  I/S  USER  HELP  REQUEST 

These  are  requests  for  help  in  using  the  automated  system. 

5.80  I/S  HELP  REQUESTS 

These  are  requests  for  help  in  determining  and  fixing  problems  beyond  the  scope  or 
ability  of  the  IRM  Operations  element. 

6.20  I/S  PERFORMANCE  REPORTS 

These  are  operations  reports  that  describe  the  effectiveness  levels,  accuracy,  usability, 
data  integrity,  software  failures,  operability,  customer  complaints,  etc.  of  the 
information  system.  The  purpose  of  these  reports  will  be  to  provide  information 
necessary  for  the  designer  to  improve  the  performance,  cost/effectiveness,  and  user 
satisfaction  levels  of  the  system. 
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6.60  I/S  USER  HELP 

This  is  the  actual  help  that  is  provided  to  the  end-user  by  whatever  form  is  necessary. 
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CONSIDERATIONS  for  ISS 
(Interim  Standard  System) 
IMPLEMENTATIONS 


OBJECTIVE  OF  THESE  NOTES 

These  notes  identify  specific  ISS  implementation  planning  considerations  that  must  be 
researched  and  analyzed  to  minimize  any  negative  impacts  on  the  Services.  They  identify 
considerations  that  are  a  direct  part  of  the  ISS  as  well  as  corollary  and  residue  implications 
on  other  parts  of  the  Service’s  information  systems. 

CURRENT  AIS  ENVIRONMENTS 

The  Service’s  current  automated  information  systems  (AISs)  operate  within  a  variety  of 
technology  environments  (Hardware  and  software).  Most  of  these  are  IBM  370  and  other 
vendor  proprietary  main-frame  architected,  which  include  an  assortment  of  architecture 
dependent  data  base  management  and  telecommunications  environments.  Complicating  the 
issue;  a  wide-array  of  operational  support  systems  for  scheduling,  capacity  management  and 
direct  access  storage  space  management  are  being  utilized.  These  environments  are  not 
"open";  the  applications  which  operate  within  them  are  heavily  dependent  upon  existing 
vendor  proprietary  architecture  environments  to  work  properly.  To  be  fair;  any  vendor 
dependent  environment  is  contrary  to  DoD’s  open  systems  goals;  not  just  IBM’s. 

CONSIDERATIONS  IN  COMBINING  ENVIRONMENTS 

The  CIM  concept  of  adopting  interim  standard  systems  (best-of-breeds)  to  be  utilized  by  all 
the  Services,  although  achievable,  could  prove  to  be  difficult  to  implement.  For  example, 
the  Material  Management  systems  of  each  of  the  Services  no  doubt  reflect 
organizational/procedural/cultural/policy  differences  of  the  Services.  These  differences  will 
manifest  themselves  in  many  ways  throughout  the  overall  information  resources  management 
environment.  Although  implementation  difficulties  may  be  minimized  through  extensive 
planning  and  resource  application,  incompatibilities  in  the  various  aspects  of  overall 
information  systems  architecture  frameworks',  should  be  expected. 


'The  framework  discussed  in  this  paper  corresponds  with  the 
framework  prescribed  by  John  A.  Zachman's  Information  Systems 
Architecture  Framework. 
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The  following  areas  must  be  analyzed  and  appropriate  planning  accomplished  in  order  to 
minimize  any  negative  effects  of  incompatibilities: 


DATA  BASE  ALIGNMENTS 

The  various  data  bases  of  the  Services  are  not  likely  to  contain  data  in  support 
of  identical  process/ function  ranges.  In  other  words  -  each  Service’s  definition 
of  Material  Management  may  overlap  more-or-less  into  other  business  areas 
such  as  Distribution,  Item  Identification,  Re-Utilization,  Contracting,  etc.  The 
inevitable  mis-alignment  of  data  will  make  it  difficult  to  eliminate  data  bases  of 
the  losing  Services  if  their  data  bases  contain  data  supporting  functions  not 
covered  in  the  chosen  service’s  application. 

DATA  ATTRIBUTE  DEFINITIONS 

There  is  no  guarantee  that  the  Services  use  standard  data  attribute  (data 
element)  names,  sizes,  or  value  ranges.  The  mis-matching  could  be 
complicated  many  times  over  by  Service  unique  data  uses  that  may  not  have 
standard  names.  For  example;  a  "Date”  attribute  may  have  a  wide  range  of 
data  uses  to  include,  date  of  entry,  completion  date,  order  date,  delivery  date, 
etc.  Although  the  apparent  characteristics  of  each  date  appear  the  same,  their 
meanings  are  entirely  different. 


Process 


PROCESS  ALIGNMENTS 

The  probability  of  the  processes  within  each  Service’s  business  areas  aligning 
100%  is  very  low.  This  is  because  there  is  not  necessarily  a  discrete  modular 
alignment  of  processes  to  business  areas.  This  means  that  when  the  interim 
standard  system  (ISS)  is  selected  or  assembled  that  a  lowest  common 
denominator  of  functionality  may  leave  the  Services  with  residue  processes  that 
would  still  need  to  be  accomplished  outside  of  the  ISS.  On  the  other  hand,  a 
combined  level  of  functionality  approach  would  almost  certainly  include 
functions  that,  in  the  other  Services,  are  out  of  that  particular  business  area’s 
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scope.  This  would  require  the  Services  to  remove  that  functionality  from  the 
corollary  processes  that  would  otherwise  be  redundant. 


Technology 

POSTPONEMENT  OF  OPEN  SYSTEMS  IDEALS 
Virtually  all  candidates  for  ISSs  currently  require  IBM  MVS  operating 
environments.  Multi-Service  sharing  and  consolidation  of  any  of  these  systems 
simply  require  larger  technology  environments  of  the  same  genre.  Although 
yielding  large  economic  advantages  it  does  not  contribute  towards  DoD’s  open 
systems  objectives. 

INABILITY  TO  QUIT  OLD  SYSTOMS 

Data  and  process  mis-alignments  will  temper  the  maximum  benefits  to  be 
gained  through  consolidations  if  any  or  all  of  the  Services  must  retain  old 
systems  or  develop  new  corollary  systems  to  operate  residue  processes  and 
data  that  were  not  accommodated  in  the  ISSs. 

AN  INDIRECT  ROUTE  TO  OPEN  SYSTEMS 
If  the  decision  remains  unchanged  to  utilize  existing  IBM  architectured 
environments  for  the  interim  standard  systems  there  is  a  devious  route  to 
attaining  open  systems.  This  route  requires  the  full  adoption  of  the  IBM 
environment  to  include  fully  embracing  IBM’s  Systems  Application 
Architecture  (SAA)  and  AD/Cycle  Repository  information  engineering 
environment.  Since  IBM  has  officially  announced  the  Corporate  objective  of 
inter-operability  between  their  SAA  and  AIX  (IBM’S  UNIX)  environments  it 
would  be  possible  to  approach  the  standard  POSIX  based  open  systems 
environment  through  IBM.  This  would  be  accomplished  through  the  use  of 
AD/Cycle  to  accomplish  the  re-engineering  and  the  use  of  IBM’s  Cross 
Systems  Product  (CSP)  to  generate  code  for  either  the  SAA  or  AIX  worlds. 
Since  AIX  and  POSIX  are  both  UNIX  based  we  will  have  achieved  the 
opportunity  to  migrate,  at  will,  to  POSIX  open  systems  or  remain  in  the  IBM 
SAA  open  environment. 


Role 


ENCLOSURE  11 


3 


CONSIDERATIONS  for  ISS 
(Interim  Standard  System) 
IMPLEMENTATIONS 


The  primary  effect  of  role  changes  within  the  Services  is  cultural.  Cultural 
changes  could  be  tenaciously  difficult  to  effect.  The  very  nature  of  Interim 
Standard  Systems  implies  that  future  changes  must  be  made  when  final 
standard  systems  are  eventually  developed.  Direct  moves  by  DoD  towards  the 
final  systems  in  the  first  phase  could  lessen  the  effect  of  subsequent  phases. 


riming 

Changes  to  the  Service’s  business  events  and  cycles  (cut-off  dates,  accounting 
periods,  batch  cycles,  external  interfaces,  etc.)  will  require  changes  to  its 
processing  schedules. 

Motivation 

Shared  ISSs  will  require  the  development  of  common  business  goals, 
strategies,  and  performance  criteria. 
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Application  consists  of  functions  A,  B,  C  and  D 


B 


t 


TM 


Distributed  Transaction 


A.S.C.O  A.B.C.O 


1 


TM 


i  A.B.C.Di 


Workload  Balancing 


B 


B 


A.B.C.D 

Host  Based 


TM 


^  ^  ^  ^ 


•A.b.c.d 


TM 


A  ^ ;  1  ;  c.D 

Hybrid  (D/T  with  W/B) 
Transaction  Manager 


This  chart  represents  various  alternatives  for  distributing 
the  functions  (processes)  of  an  application  over  multiple 
processors.  Transaction  management  logic,  which  could  be 
located  in  any  of  the  processors,  would  supervise  the 
distribution  of  work  (transactions)  according  to  the  scheme 
(Distributed  transaction  /  Workload  balancing)  desired. 

Distributed  transaction  processing  takes  place  when 
functions  are  distributed.  Workload  balancing  is  when  the 
same  functions  may  be  handled  in  multiple  processors  and 

processor  availability  is  the  key  factor  in  distribution 

of  work. 
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